[Sipping] RE: Sipping Digest, Vol 15, Issue 30

[Janardhana <[e-mail]>]

Hi,
 Can any one please clarify me on bellow SIP grammer doubt.

>From RFC3261 grammer
  userinfo rule is
	userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
  Authority rule is
	authority = srvr / reg-name
	srvr = [ [ userinfo "@" ] hostport ]

In the above Authority srvr rule if i expand userinfo rule then it becomes
as bellow
	srvr = [[( user / telephone-subscriber ) [ ":" password ] "@" "@"]hostPort]
at the end of the userinfo there are two @ symbols.

Is that expected ? or it has to be only one "@"?
Please clarify me.

Thanks & Regards
-Janardhana


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of [e-mail]
Sent: Friday, July 15, 2005 9:39 PM
To: [e-mail]
Subject: Sipping Digest, Vol 15, Issue 30


Send Sipping mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sipping
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sipping digest..."


Today's Topics:

   1. RE: AW: AW: AW: AW: [Sipping] Re: New Draft on TISPAN
      analysis	forSI	P so	luti onsc oncerning the simulation Services
      (Warren, Dan, VF UK - Technology (TS))
   2. Re: AW: AW: AW: AW: [Sipping] Re: New Draft on TISPAN
      analysis forSI	P so	luti onsc oncerning the simulation Services
      (Paul Kyzivat)
   3. Re: Re: New Draft on TISPAN analysis for SIP solutions
      concerning the simulation Services (David R Oran)


----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Jul 2005 15:35:17 +0100
From: "Warren, Dan, VF UK - Technology \(TS\)"
	<[e-mail]>
Subject: RE: AW: AW: AW: AW: [Sipping] Re: New Draft on TISPAN
	analysis	forSI	P so	luti onsc oncerning the simulation Services
To: "Paul Kyzivat" <[e-mail]>, "Jesske, R"
	<[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-ID: <F2ED377449FFFC4FBD24C8B5CFEB2DB032C8B8@UKWMXM11>
Content-Type: text/plain;	charset="iso-8859-1"

Paul, all

That sounds about right to me as analysis of this goes, and I think it has
to be ok with TISPAN because it is the situation that would occur today, if
instead of a 'TISPAN conforming sip endpoint on a TISPAN conforming sip
network', the call is originated from a PSTN using ISUP.

Fundamentally, I think TISPAN's concern is with regard to loss of existing
functionality or degradation of end user experience because of what
regulators would have to say about this.  The fact that no indication is
returned from the vanilla-SIP UA isn't a degradation since there would be no
indication today, right?

Dan

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Paul Kyzivat
> Sent: 15 July 2005 14:55
> To: Jesske, R
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: AW: AW: AW: AW: [Sipping] Re: New Draft on
> TISPAN analysis
> forSI P so luti onsc oncerning the simulation Services
>
>
>
>
> Jesske, R wrote:
>
> >>My question is: do you expect (or desire, or require) native sip
> >>components (not conforming to TISPAN specifications) to
> insert these
> >>reason codes?
> >
> >
> > Yes
> > it shall be included by UA (a TISPAN AS could be a UA also
> a ISUP Gateway acts as UA)
> > and
> > it shall be included or forwarded by Proxies.
> >
> > TISPAN profiles then the use of the RFC for their purposes
> as it was done with other RFCs.
> >
> > I know that this generic aproach allows the inclusion by
> each endclient. Of course then the PSTN/ISDN Gateway or
> Gateway to a private network (e.G ETSI TISPAN NGN) has to
> take care it. If the Reason shall be mapped or not.
> >
> > I think it is better to have a generic aproach with UA and
> Proxy behavior.
>
> I still don't see how this can work except in a closed
> network where all
> the endpoints conform to your specific requirements.
>
> Specifically, suppose a TISPAN conforming sip endpoint on a TISPAN
> conforming sip network calls a sip endpoint that is outside of the
> TISPAN network, and that conforms only to basic 3261. (This would
> perhaps be via some sip peering agreement, or simply by having the
> TISPAN network resolve a foreign sip address according to 3263.
>
> The request from the TISPAN endpoint indicates that it wants to block
> transmission of its address, and so the request, when it reaches the
> target, specifies an anonymous address. The target sip
> endpoint does not
> accept calls from anonymous callers. So perhaps it responds
> with a 403
> Forbidden. It does not include a Reason header, especially
> not one with
> a Q.850 error code 24, because it is not a party to TISPAN agreements
> that it should do so.
>
> As a result, the TISPAN caller has its call rejected, but
> does not get
> the indication that this was due to anonymous call rejection, even
> though that was in fact the reason.
>
> This same situation holds if the "TISPAN caller" is in fact a PSTN
> gateway, so that PSTN callers may also not get the indication of
> anonymous call rejection.
>
> So either you must be content that indication of anonymous call
> rejection only works when SIP participants conform to the TISPAN
> profile, or else you are going to have to get all the sip
> endpoints in
> the world to conform to some TISPAN requirements.
>
> I just want to understand if that is the situation as you
> understand it.
>
> 	Paul
>
> >>If so, I think you must eventually produce a standards
> track document
> >>that specifies the desired behavior. AFAIK there currently
> exists no
> >>document that specifies when and if a sip node should insert Q.850
> >>reason codes into its sip messages.
> >
> >
> > The Reason RFC 3326  is very vague with regard of entities
> including the Reason header. From my interpretation of
> RFC3326 a Reason header can be included by UA's and Proxies.
> >
> > So to be inline with RFC 3326 I have nothing against to
> keep this as it was defined.
> >
> >
> >
> >
> >>	Paul
> >
> >
> > Jesske, R wrote:
> >
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>



------------------------------

Message: 2
Date: Fri, 15 Jul 2005 11:21:47 -0400
From: Paul Kyzivat <[e-mail]>
Subject: Re: AW: AW: AW: AW: [Sipping] Re: New Draft on TISPAN
	analysis forSI	P so	luti onsc oncerning the simulation Services
To: "Warren, Dan, VF UK - Technology \(TS\)" <[e-mail]>
Cc: "Jesske, R" <[e-mail]>, [e-mail],
	[e-mail], [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed

I hope so. It is very difficult for me to tell what the expectations are
here. It seems that we don't speak the same language.

	Paul

Warren, Dan, VF UK - Technology (TS) wrote:
> Paul, all
>
> That sounds about right to me as analysis of this goes, and I think it has
to be ok with TISPAN because it is the situation that would occur today, if
instead of a 'TISPAN conforming sip endpoint on a TISPAN conforming sip
network', the call is originated from a PSTN using ISUP.
>
> Fundamentally, I think TISPAN's concern is with regard to loss of existing
functionality or degradation of end user experience because of what
regulators would have to say about this.  The fact that no indication is
returned from the vanilla-SIP UA isn't a degradation since there would be no
indication today, right?
>
> Dan
>
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of Paul Kyzivat
>>Sent: 15 July 2005 14:55
>>To: Jesske, R
>>Cc: [e-mail]; [e-mail]; [e-mail]
>>Subject: Re: AW: AW: AW: AW: [Sipping] Re: New Draft on
>>TISPAN analysis
>>forSI P so luti onsc oncerning the simulation Services
>>
>>
>>
>>
>>Jesske, R wrote:
>>
>>
>>>>My question is: do you expect (or desire, or require) native sip
>>>>components (not conforming to TISPAN specifications) to
>>>
>>insert these
>>
>>>>reason codes?
>>>
>>>
>>>Yes
>>>it shall be included by UA (a TISPAN AS could be a UA also
>>
>>a ISUP Gateway acts as UA)
>>
>>>and
>>>it shall be included or forwarded by Proxies.
>>>
>>>TISPAN profiles then the use of the RFC for their purposes
>>
>>as it was done with other RFCs.
>>
>>>I know that this generic aproach allows the inclusion by
>>
>>each endclient. Of course then the PSTN/ISDN Gateway or
>>Gateway to a private network (e.G ETSI TISPAN NGN) has to
>>take care it. If the Reason shall be mapped or not.
>>
>>>
>>>I think it is better to have a generic aproach with UA and
>>
>>Proxy behavior.
>>
>>I still don't see how this can work except in a closed
>>network where all
>>the endpoints conform to your specific requirements.
>>
>>Specifically, suppose a TISPAN conforming sip endpoint on a TISPAN
>>conforming sip network calls a sip endpoint that is outside of the
>>TISPAN network, and that conforms only to basic 3261. (This would
>>perhaps be via some sip peering agreement, or simply by having the
>>TISPAN network resolve a foreign sip address according to 3263.
>>
>>The request from the TISPAN endpoint indicates that it wants to block
>>transmission of its address, and so the request, when it reaches the
>>target, specifies an anonymous address. The target sip
>>endpoint does not
>>accept calls from anonymous callers. So perhaps it responds
>>with a 403
>>Forbidden. It does not include a Reason header, especially
>>not one with
>>a Q.850 error code 24, because it is not a party to TISPAN agreements
>>that it should do so.
>>
>>As a result, the TISPAN caller has its call rejected, but
>>does not get
>>the indication that this was due to anonymous call rejection, even
>>though that was in fact the reason.
>>
>>This same situation holds if the "TISPAN caller" is in fact a PSTN
>>gateway, so that PSTN callers may also not get the indication of
>>anonymous call rejection.
>>
>>So either you must be content that indication of anonymous call
>>rejection only works when SIP participants conform to the TISPAN
>>profile, or else you are going to have to get all the sip
>>endpoints in
>>the world to conform to some TISPAN requirements.
>>
>>I just want to understand if that is the situation as you
>>understand it.
>>
>>	Paul
>>
>>
>>>>If so, I think you must eventually produce a standards
>>>
>>track document
>>
>>>>that specifies the desired behavior. AFAIK there currently
>>>
>>exists no
>>
>>>>document that specifies when and if a sip node should insert Q.850
>>>>reason codes into its sip messages.
>>>
>>>
>>>The Reason RFC 3326  is very vague with regard of entities
>>
>>including the Reason header. From my interpretation of
>>RFC3326 a Reason header can be included by UA's and Proxies.
>>
>>>So to be inline with RFC 3326 I have nothing against to
>>
>>keep this as it was defined.
>>
>>>
>>>
>>>
>>>
>>>>	Paul
>>>
>>>
>>>Jesske, R wrote:
>>>
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP
>>Use [e-mail] for questions on current sip
>>Use [e-mail] for new developments of core SIP
>>
>
>



------------------------------

Message: 3
Date: Fri, 15 Jul 2005 11:27:43 -0400
From: David R Oran <[e-mail]>
Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP
	solutions	concerning the simulation Services
To: Miguel Garcia <[e-mail]>
Cc: sipping WG <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed


On Jul 5, 2005, at 7:43 AM, Miguel Garcia wrote:

> Hi Davd:
>
> Because bodies are supposed to be end-to-end information, so if a
> UA inserts a body, a proxy shouldn't be touching it, otherwise, it
> wouldn't be a proxy, but a B2BUA or UA. So having a body here will
> just limit the operation of the application server to B2BUAs.
>
I suppose that's ok, but I'd really like to see the analysis and
justification in the draft. I'd especially like to know why the
proxies should be involved in what it actually an end-to-end function
as far as I can tell based on the kind of stuff people put in AOC
fields.

I don't have web proxy caches telling me what I was being charged for
in a web transaction...


> We want to have the possibility of the application server that
> provides the AoC information to behave as a SIP proxy, just reading
> the header, and then providing the information by other means. For
> instance, it has been discussed that the application server could
> send an Instant Message to the UA containing either the information
> or a content indirection link. This instant message will go out of
> the existing dialog, so the application server could be acting as a
> UA for the instant message.
>
If you want the proxy to see this information, you can always not
encrypt it...

> BR,
>
>       Miguel
>
> David R Oran wrote:
>
>
>> Would you please provide justification in the draft for why this
>> should be a header and not a body? I can't for the life of me
>> figure  out why this can't be done with a body (which would
>> require  essentially no change to SIP, only a MIME registration)
>> since proxies  do nothing with the header I can discern.
>> Thanks, Dave.
>> On Jul 1, 2005, at 2:56 AM, Miguel Garcia wrote:
>>
>>> And I have also submitted another draft that proposes a P-
>>> header  to support the Advice of Charge service.
>>>
>>> Until the draft is officially distributed, it can be retrieved from:
>>>
>>> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-etsi-
>>> ngn-p-headers-00.txt
>>>
>>> /Miguel
>>>
>>> Jesske, R wrote:
>>>
>>>
>>>
>>>
>>>> Dear all,
>>>> A new draft regarding the analysis of the requirements on
>>>> TISPAN  simulation services as described in draft-jesske-sipping-
>>>> tispan- requirements-01  is now available.
>>>> It can be fond under:
>>>> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-
>>>> analysis-00.txt We would like to start the discussion on
>>>> solutions  for the requirements we stated in draft-jesske-
>>>> sipping-tispan- requirements-01 (http://www.ietf.org/internet-
>>>> drafts/draft-jesske- sipping-tispan-requirements-01.txt).
>>>> This draft should be seen as a discussion basis and
>>>> brainstorming  of some people thinking about SIP solutions.
>>>> Every comment and discussion is welcome and helps to find a
>>>> solution.
>>>> Thank you.
>>>> Best Regards
>>>> Roland
>>>> Deutsche Telekom AG
>>>> T-Com Zentrale
>>>> Roland Jesske, TE332-2
>>>> Section TE33; Signalling, Gateways and Switching Systems
>>>> Am Kavalleriesand 3, 64295 Darmstadt, Germany
>>>> Phone:  [phone]
>>>> Fax:      [phone]
>>>> email:   [e-mail]
>>>>
>>>>
>>>
>>> --
>>> Miguel A. Garcia           tel:[phone]
>>> sip:[e-mail]
>>> Nokia Research Center      Helsinki, Finland
>>>
>>>
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use [e-mail] for questions on current sip
>>> Use [e-mail] for new developments of core SIP
>>>
>>>
>
> --
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>



------------------------------

Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

End of Sipping Digest, Vol 15, Issue 30
***************************************


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP