Hi, I want to know - what is the status of status of draft-ietf-sip-gruu-15?
Thanks, Dushyant P S Dhalia -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 1:21 PM To: [email protected] Subject: Sip-implementors Digest, Vol 67, Issue 1 Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip-implementors digest..." Today's Topics: 1. Re: Few offer/answer queries (Vikram Chhibber) 2. Re: SIP and firewalls (krishna kalluri) 3. Re: Few offer/answer queries (Brett Tate) 4. Re: SIP and firewalls (Paul Darling) 5. Re: Problem compiling (Attila Sipos) 6. Who responds to an OPTIONS request if PUBLISH is supported? (Franz Edler) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Sep 2008 22:04:12 +0530 From: "Vikram Chhibber" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] Few offer/answer queries To: "Harsha. R" <[EMAIL PROTECTED]> Cc: "[email protected]" <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Thanks Harsha, this is what I was also expecting. I just wanted some formal description on this and I found it in http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.tx t o In the o-line, only the version number may change, and if it changes it must increment by one from the one previously sent as an offer or answer. (RFC 3264 [4] section 8.) If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. Changing the o-line, except version number value, during the session is an error case. The behavior when receiving such a non-compliant offer/answer SDP body is implementation dependent. If a UA needs to negotiate a 'new' SDP session, it should use the INVITE/Replaces method. Thus, I can conclude that SDP session-ids of either party can not change under established SIP dialog? A SIP B2BUA also needs to take care of "o" line conformance besides transforming SIP messages from one dialog leg to another if it wants to implement feature like network side music-on-hold or call-transfer. Does anyone have any other inputs? Thanks, ~Vikram On Tue, Sep 30, 2008 at 4:06 PM, Harsha. R <[EMAIL PROTECTED]>wrote: > Vikram, > > Session id is kept constant across offers/answers sent by UAC/UAS. Only > Session version is incremented for > every new offer/answer sent by UAC/UAS. > > > The reason UA *MUST NOT* change session id can probably be inferred from > SDP RFC 4566, section 5.2 > > <sess-id> is a numeric string such that the tuple of <username>, > <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a > globally unique identifier for the session. > > Therefore by changing the session id, you are changing the identifier for > the session for either a UAC/UAS > > To answer your specific questions. > > >What is the behavior of the receiver if it receives offer with different > "session id" in > >re-INVITE or UPDATE? > > Take down the call as REINVITE o-line with a new session id identifies a > session that does not exist at UA. > > >Also, what should be the behavior of the receiver if it > >receives offer with same "session id" as previous but with version > >incremented more than one? > > IMO, a liberal implementation *SHOULD* allow this offer/answer to proceed. > For me, this bears similarity > to the case when CSeq is incremented more than 1 for a subsequent request > from a UAC. > > >b) We emphasize that UAS should send back its full capability offer in > >response to offer-less re-INVITE. Does that also have "SDP session > >resetting" effect in the sense that the answer SDP MAY not have same "o" > >line session-id as sent by remote previously? This scenario comes when you > >are trying to negotiate media-session with another entity within an > >established SIP dialog say network side call-transfer. > > In this case of forced SDP offer, UAS must use the same session id in the > offer it sends, as it sent in a previous answer(in either 18X response/200 > OK INVITE), and increment the session version by 1. > > Regards > Harsha > > 2008/9/30 Vikram Chhibber <[EMAIL PROTECTED]> > >> Hi All, >> >> >> >> I have few queries on RFC 3264: An Offer/Answer Model with the Session >> Description Protocol (SDP): >> >> >> >> 8 Modifying the Session >> >> .... >> >> When issuing an offer that modifies the session, >> >> the "o=" line of the new SDP MUST be identical to that in the >> >> previous SDP, except that the version in the origin field MUST >> >> increment by one from the previous SDP. >> >> >> >> The aforementioned statement defines the "o" line creation in the offer by >> the sender. >> >> >> >> a) Does this also mean that the receiver must always expect same "session >> id" in all the subsequent offers after initial offer/answer? What is the >> behavior of the receiver if it receives offer with different "session id" >> in >> re-INVITE or UPDATE? Also, what should be the behavior of the receiver if >> it >> receives offer with same "session id" as previous but with version >> incremented more than one? >> >> Are the above scenarios "legal" for UA or should it treat these normally >> and >> continue by following philosophy of being strict while sending and lenient >> while receiving? >> >> >> >> b) We emphasize that UAS should send back its full capability offer in >> response to offer-less re-INVITE. Does that also have "SDP session >> resetting" effect in the sense that the answer SDP MAY not have same "o" >> line session-id as sent by remote previously? This scenario comes when you >> are trying to negotiate media-session with another entity within an >> established SIP dialog say network side call-transfer. >> >> >> >> Thanks, >> >> ~Vikram >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > > > -- > Regards > Harsha > ------------------------------ Message: 2 Date: Tue, 30 Sep 2008 18:39:24 +0200 From: "krishna kalluri" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] SIP and firewalls To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, If you are not aware this draft please take a look. I found it very useful to understand the nat and firewall scenarios. http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09 Regards Krishna > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Sep 2008 14:58:23 -0700 > From: "Paul Darling" <[EMAIL PROTECTED]> > Subject: [Sip-implementors] SIP and firewalls > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Please allow a newbie question.. > > My management is considering providing as a host/Saas service, the SIP > server that I'm developing. This raises questions regarding firewall > impact > between SIP client and server. > > In particular, externally initiated requests, such as NOTIFY, will more > than > likely be rejected by a firewall, even if outbound TCP request/response is > enabled. > > >From brief research, I see there are Sip-capable firewalls, and RFC 3261 > refers to use of a Back-to-Back User Agent. > > Can anyone tell me what the the current thinking is on this issue? > > As a hosted service, it would be preferable for our users not to need to > install any devices or software on their network to use our SIP server. > But > this seems unavoidable. > > sincerely, > Paul > > > ------------------------------ Message: 3 Date: Tue, 30 Sep 2008 13:01:24 -0400 From: "Brett Tate" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] Few offer/answer queries To: "Vikram Chhibber" <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Since you mentioned B2BUA and some related services... RFC 3725 also discusses the origin impacts for RFC 3264 compliance. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Vikram Chhibber > Sent: Tuesday, September 30, 2008 12:34 PM > To: Harsha. R > Cc: [email protected] > Subject: Re: [Sip-implementors] Few offer/answer queries > > Thanks Harsha, this is what I was also expecting. I just > wanted some formal description on this and I found it in > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-off > eranswer-08.txt > > > > o In the o-line, only the version number may change, and if it > > changes it must increment by one from the one previously sent as > > an offer or answer. (RFC 3264 [4] section 8.) If it doesn't > > change then the entire SDP body must be identical to what was > > previously sent as an offer or answer. Changing the o-line, > > except version number value, during the session is an error case. > > The behavior when receiving such a non-compliant offer/answer > > SDP body is implementation dependent. If a UA needs to negotiate > > a 'new' SDP session, it should use the INVITE/Replaces method. > > > > > > Thus, I can conclude that SDP session-ids of either party can > not change under established SIP dialog? A SIP B2BUA also > needs to take care of "o" > line conformance besides transforming SIP messages from one > dialog leg to another if it wants to implement feature like > network side music-on-hold or call-transfer. > > Does anyone have any other inputs? > > Thanks, > ~Vikram > > On Tue, Sep 30, 2008 at 4:06 PM, Harsha. R > <[EMAIL PROTECTED]>wrote: > > > Vikram, > > > > Session id is kept constant across offers/answers sent by UAC/UAS. > > Only Session version is incremented for every new > offer/answer sent by > > UAC/UAS. > > > > > > The reason UA *MUST NOT* change session id can probably be inferred > > from SDP RFC 4566, section 5.2 > > > > <sess-id> is a numeric string such that the tuple of <username>, > > <sess-id>, <nettype>, <addrtype>, and > <unicast-address> forms a > > globally unique identifier for the session. > > > > Therefore by changing the session id, you are changing the > identifier > > for the session for either a UAC/UAS > > > > To answer your specific questions. > > > > >What is the behavior of the receiver if it receives offer with > > >different > > "session id" in > > >re-INVITE or UPDATE? > > > > Take down the call as REINVITE o-line with a new session id > identifies > > a session that does not exist at UA. > > > > >Also, what should be the behavior of the receiver if it receives > > >offer with same "session id" as previous but with version > incremented > > >more than one? > > > > IMO, a liberal implementation *SHOULD* allow this > offer/answer to proceed. > > For me, this bears similarity > > to the case when CSeq is incremented more than 1 for a subsequent > > request from a UAC. > > > > >b) We emphasize that UAS should send back its full > capability offer > > >in response to offer-less re-INVITE. Does that also have > "SDP session > > >resetting" effect in the sense that the answer SDP MAY not > have same "o" > > >line session-id as sent by remote previously? This scenario comes > > >when you are trying to negotiate media-session with another entity > > >within an established SIP dialog say network side call-transfer. > > > > In this case of forced SDP offer, UAS must use the same > session id in > > the offer it sends, as it sent in a previous answer(in either 18X > > response/200 OK INVITE), and increment the session version by 1. > > > > Regards > > Harsha > > > > 2008/9/30 Vikram Chhibber <[EMAIL PROTECTED]> > > > >> Hi All, > >> > >> > >> > >> I have few queries on RFC 3264: An Offer/Answer Model > with the Session > >> Description Protocol (SDP): > >> > >> > >> > >> 8 Modifying the Session > >> > >> .... > >> > >> When issuing an offer that modifies the session, > >> > >> the "o=" line of the new SDP MUST be identical to that in the > >> > >> previous SDP, except that the version in the origin field MUST > >> > >> increment by one from the previous SDP. > >> > >> > >> > >> The aforementioned statement defines the "o" line creation in the > >> offer by the sender. > >> > >> > >> > >> a) Does this also mean that the receiver must always expect same > >> "session id" in all the subsequent offers after initial > offer/answer? > >> What is the behavior of the receiver if it receives offer > with different "session id" > >> in > >> re-INVITE or UPDATE? Also, what should be the behavior of the > >> receiver if it receives offer with same "session id" as > previous but > >> with version incremented more than one? > >> > >> Are the above scenarios "legal" for UA or should it treat these > >> normally and continue by following philosophy of being > strict while > >> sending and lenient while receiving? > >> > >> > >> > >> b) We emphasize that UAS should send back its full > capability offer > >> in response to offer-less re-INVITE. Does that also have > "SDP session > >> resetting" effect in the sense that the answer SDP MAY not > have same "o" > >> line session-id as sent by remote previously? This scenario comes > >> when you are trying to negotiate media-session with another entity > >> within an established SIP dialog say network side call-transfer. > >> > >> > >> > >> Thanks, > >> > >> ~Vikram > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > > > > > > -- > > Regards > > Harsha > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ------------------------------ Message: 4 Date: Tue, 30 Sep 2008 10:13:54 -0700 From: "Paul Darling" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] SIP and firewalls To: "krishna kalluri" <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Thanks everyone for the information and pointers. There's much here about NAT traversal, but not so much about requests initiated from the public network blocked by a firewall. If I understand correctly, this is obviated by connection reuse, requiring connections to be kept alive for the server to send requests over to a registered UA. Is that generally the idea? Ideally there would be a solution that does not require client support for protocol extensions such as are documented in the "outbound" draft document. My hosted SIP service should support existing clients/UAs. In this case, the use of a SIP enabled firewall or Session Border Control device may be required. In any case, I may have more cogent questions when I've had time to digest all the new information you have given me. Thanks! On Tue, Sep 30, 2008 at 9:39 AM, krishna kalluri <[EMAIL PROTECTED]>wrote: > Hi Paul, > > If you are not aware this draft please take a look. I found it very useful > to understand the nat and firewall scenarios. > > http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09 > > Regards > Krishna > > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 29 Sep 2008 14:58:23 -0700 >> From: "Paul Darling" <[EMAIL PROTECTED]> >> Subject: [Sip-implementors] SIP and firewalls >> To: [email protected] >> Message-ID: >> <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Please allow a newbie question.. >> >> My management is considering providing as a host/Saas service, the SIP >> server that I'm developing. This raises questions regarding firewall >> impact >> between SIP client and server. >> >> In particular, externally initiated requests, such as NOTIFY, will more >> than >> likely be rejected by a firewall, even if outbound TCP request/response is >> enabled. >> >> >From brief research, I see there are Sip-capable firewalls, and RFC 3261 >> refers to use of a Back-to-Back User Agent. >> >> Can anyone tell me what the the current thinking is on this issue? >> >> As a hosted service, it would be preferable for our users not to need to >> install any devices or software on their network to use our SIP server. >> But >> this seems unavoidable. >> >> sincerely, >> Paul >> >> >> > ------------------------------ Message: 5 Date: Tue, 30 Sep 2008 19:09:35 +0100 From: "Attila Sipos" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] Problem compiling To: "Javier Fileiv - Posthac S.A." <[EMAIL PROTECTED]>, <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" no idea. I find the following usually works for installing software on linux: ./configure make make install I think I had to build osip once - it was for a pentium-based linux and I think I used the commands given above. Regards, Attila ________________________________ From: [EMAIL PROTECTED] on behalf of Javier Fileiv - Posthac S.A. Sent: Tue 30/09/2008 16:47 To: [email protected] Subject: [Sip-implementors] Problem compiling Hi everyone! I need to build the osip library to ARM architecture (running on uClinux) but i don't know how to do it. Please can give some help? Thanks a lot, best regards. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 6 Date: Wed, 1 Oct 2008 09:51:09 +0200 From: "Franz Edler" <[EMAIL PROTECTED]> Subject: [Sip-implementors] Who responds to an OPTIONS request if PUBLISH is supported? To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi all, I just stumble on a question regarding the OPTIONS request. According to RFC 3261 the OPTIONS request is answered by the server addressed in the request URI, this may be a proxy or a user agent. But now I read in RFC 3903 (SIP Event State Publication) that the OPTIONS request can be used to probe if PUBLISH is supported. In this case I guess the ESC (Event State Compositor) should answer. That is a different network element that the user agent addressed above. How can this mechanism work when different targets are to be addressed by an OPTIONS request? Who can help me clarify the situation? Regards Franz ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 67, Issue 1 *********************************************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
