Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Paul Kyzivat wrote: Dale has covered this. For the original poster, Stefan: there is a lot of written information on this subject that you don't seem to be familiar with. The most obvious are RFCs 3261 and 3264. For a more I wonder how I made the impression to not be familiar with 3264, as I mentioned the requirement from it to increase the o-line version number if the session is to be modified (8 Modifying the Session): The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the previous SDP. If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below. [...] 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. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. I would say it makes sense to increase the version in the origin line as well as apply the other constraints to the modified answer too, but the text does not really say that, unlike complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt where you write in 4.2.5. Subsequent Offers and Answers: 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. If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. Once you understand those I think your questions will be answered. Paul Regards Stefan Sayer ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
[EMAIL PROTECTED] wrote: In regard to how the answer may be different from the offer, the rules are in section 6.1 of RFC 3264. In many cases, the answerer may add media formats. E.g., For streams marked as sendrecv in the answer, the m= line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). the payloads from the second answer are the same as the ones from the second offer (just in different order): 1st offer: Session ID: 251733463 Session Version: 1181517354 payloads: 3 98 97 8 0 101 1st answer: Session ID: 162119823 Session Version: 1294106766 payloads: 3 101 ... 2nd offer: Session ID: 251733463 Session Version: 1181517354 payloads: 3 98 97 8 0 101 2nd answer: Session ID: 162119823 Session Version: 1294106766 payloads: 98 97 8 0 3 101 In any case, if one is trying to debug SDP, one should have read RFC 3264 carefully. how true. Regards Stefan Sayer -- iptego - VoIP security www.iptego.de ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Stefan, Sorry I misunderstood your level of research. The version number should be incremented if the sdp is different from the prior one sent in the same direction, whether this is in the offer or the answer. It *should* remain unchanged if the rest of the sdp is unchanged. (But I think there is no serious harm in incrementing it in this case too if you haven't kept track of whether it has changed.) Paul Stefan Sayer wrote: Paul Kyzivat wrote: Dale has covered this. For the original poster, Stefan: there is a lot of written information on this subject that you don't seem to be familiar with. The most obvious are RFCs 3261 and 3264. For a more I wonder how I made the impression to not be familiar with 3264, as I mentioned the requirement from it to increase the o-line version number if the session is to be modified (8 Modifying the Session): The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the previous SDP. If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below. [...] 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. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. I would say it makes sense to increase the version in the origin line as well as apply the other constraints to the modified answer too, but the text does not really say that, unlike complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt where you write in 4.2.5. Subsequent Offers and Answers: 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. If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. Once you understand those I think your questions will be answered. Paul Regards Stefan Sayer ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
From what I can see of the example below there is only one problem - the version number in the 2nd answer should have been incremented. As written, the offerer could proceed on the assumption that the answer has not changed. In this case that would do no harm. In some other cases it might. Paul Stefan Sayer wrote: [EMAIL PROTECTED] wrote: In regard to how the answer may be different from the offer, the rules are in section 6.1 of RFC 3264. In many cases, the answerer may add media formats. E.g., For streams marked as sendrecv in the answer, the m= line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). the payloads from the second answer are the same as the ones from the second offer (just in different order): 1st offer: Session ID: 251733463 Session Version: 1181517354 payloads: 3 98 97 8 0 101 1st answer: Session ID: 162119823 Session Version: 1294106766 payloads: 3 101 ... 2nd offer: Session ID: 251733463 Session Version: 1181517354 payloads: 3 98 97 8 0 101 2nd answer: Session ID: 162119823 Session Version: 1294106766 payloads: 98 97 8 0 3 101 In any case, if one is trying to debug SDP, one should have read RFC 3264 carefully. how true. Regards Stefan Sayer ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Stefan Sayer [EMAIL PROTECTED] wrote: complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt where you write in 4.2.5. Subsequent Offers and Answers: 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. If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. This is the most often misimplemented part. It's usual to see UAs which send e.g. SDP with session ID and version both identical and showed a time from session start, either for the same SDP or changed one; or in another broken mode. In practice, one shall never rely on this (in 4.2.5) rule. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Valentin Nechayev wrote: Stefan Sayer [EMAIL PROTECTED] wrote: complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt where you write in 4.2.5. Subsequent Offers and Answers: 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. If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. This is the most often misimplemented part. It's usual to see UAs which send e.g. SDP with session ID and version both identical and showed a time from session start, either for the same SDP or changed one; or in another broken mode. In practice, one shall never rely on this (in 4.2.5) rule. I have always found the use of the o-line in o/a to be at best dangerous. It is redundant information. I'm not sufficiently trusting to believe it when it says nothing has been changed. At best I would want to verify that it is the same, and if doing that, its probably just as easy to process as if it had changed and discover you have the null change. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Beware that there is a some confusion in this thread. In particular, the SDP that we've been discussing is from Manjunath Warad's message of Mon, 06 Aug 2007 11:19:24 +0530, in which he states: I have strong doubt on the SDP that is exchanged in 200 of Re-INVITE. Answerer has added other media formats that he supports and I don't think offerer would support those and hence offerer could be releasing the call by sending ACK and BYE. However, examining the SDP shows that the answer has *not* added other media formats. (Although doing so is allowed.) From: Stefan Sayer [EMAIL PROTECTED] the payloads from the second answer are the same as the ones from the second offer (just in different order): See above. In any case, if one is trying to debug SDP, one should have read RFC 3264 carefully. how true. My statement here was more directed toward Manjunath, as RFC 3264 answers his question. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Hi, complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt where you write in 4.2.5. Subsequent Offers and Answers: 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. If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. This is the most often misimplemented part. It's usual to see UAs which send e.g. SDP with session ID and version both identical and showed a time from session start, either for the same SDP or changed one; or in another broken mode. In practice, one shall never rely on this (in 4.2.5) rule. I don't agree. Also the SDP spec says that the version shall be incremented if the SDP information changes, so if one doesn't do it I think it's a clear protocol error. There are use-cases where you are going to send an un-changed SDP, for example if you are using the session-timer mechanism, or if you are updating the local target, in which case the version is not incremented. It is very useful information for the receiver, because it knows it doesn't need to start processing the SDP, compare it with previous SDPs etc. Regards, Christer -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
From: Stefan Sayer [EMAIL PROTECTED] The offerer may change the stream, but the answerer? Uh, yes. I answered a different question than was asked. In regard to how the answer may be different from the offer, the rules are in section 6.1 of RFC 3264. In many cases, the answerer may add media formats. E.g., For streams marked as sendrecv in the answer, the m= line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). In any case, if one is trying to debug SDP, one should have read RFC 3264 carefully. From: Stefan Sayer [EMAIL PROTECTED] And then, if you change any part of the SDP, you must update (increase) the session version, which in both SDPs of the two 200s is 1294106766. Interestingly, though the offers are identical, the answers are different (and so should have different versions). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Dale has covered this. For the original poster, Stefan: there is a lot of written information on this subject that you don't seem to be familiar with. The most obvious are RFCs 3261 and 3264. For a more complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt Once you understand those I think your questions will be answered. Paul [EMAIL PROTECTED] wrote: From: Stefan Sayer [EMAIL PROTECTED] The offerer may change the stream, but the answerer? Uh, yes. I answered a different question than was asked. In regard to how the answer may be different from the offer, the rules are in section 6.1 of RFC 3264. In many cases, the answerer may add media formats. E.g., For streams marked as sendrecv in the answer, the m= line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). In any case, if one is trying to debug SDP, one should have read RFC 3264 carefully. From: Stefan Sayer [EMAIL PROTECTED] And then, if you change any part of the SDP, you must update (increase) the session version, which in both SDPs of the two 200s is 1294106766. Interestingly, though the offers are identical, the answers are different (and so should have different versions). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
From: Manjunath Warad [EMAIL PROTECTED] I have strong doubt on the SDP that is exchanged in 200 of Re-INVITE. Answerer has added other media formats that he supports and I don't think offerer would support those and hence offerer could be releasing the call by sending ACK and BYE. Why do you have doubt? Read RFC 3264 (An Offer/Answer Model with the Session Description Protocol (SDP)), section 8 (Modifying the Session), subsection 8.3 (Modifying a Media Stream), subsection 8.3.2 (Changing the Set of Media Formats): The list of media formats used in the session MAY be changed. To do this, the offerer creates a new media description, with the list of media formats in the m= line different from the corresponding media stream in the previous SDP. This list MAY include new formats, and MAY remove formats present from the previous SDP. However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Can you also attach the original INVITE call flow along with re-INVITE? That can help to compare the SDP versions, CSeq etc. Also, if everything turns out to be OK, then there may be some policy (private) based on which it might be rejecting! Somesh [EMAIL PROTECTED] wrote: Hi, I'm havin a problem sending a re-invite message to change the current SDP-Session. The Reinvite itsself causes the receiver to generate an OK message with its SDP. But after receiving the following Request ACK it just generates a BYE and ends. Does anyone see the problem? Is the Reinvite correct? Are the CSeqs ok? many thanks in advance!! Andreas packet capture: [RE-INVITE:] Session Initiation Protocol Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Message Header Record-Route: Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.0 Via: SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4bKfzzdcjdi Max-Forwards: 69 To: ;tag=dyyrq From: ;tag=dochj Call-ID: [EMAIL PROTECTED] CSeq: 996 INVITE Sequence Number: 996 Method: INVITE Contact: Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO Supported: replaces,norefersub,100rel User-Agent: Twinkle/1.0 Content-Length: 305 P-hint: usrloc applied Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 100 295838384 725581350 IN IP4 134.2.172.238 Owner Username: 100 Session ID: 295838384 Session Version: 725581350 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 134.2.172.238 Session Name (s): - Connection Information (c): IN IP4 134.2.172.238 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 134.2.172.238 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8000 RTP/AVP 3 98 97 8 0 101 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute (a): * [OK, WITH SESSION DESCRIPTION] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.0,SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4bKfzzdcjdi To: ;tag=dyyrq From: ;tag=dochj Call-ID: [EMAIL PROTECTED] CSeq: 996 INVITE Sequence Number: 996 Method: INVITE Contact: Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO Server: Twinkle/1.0 Supported: replaces,norefersub Content-Length: 304 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 101 1577192660 821447339 IN IP4 134.2.173.47 Owner Username: 101 Session ID: 1577192660 Session Version: 821447339 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 134.2.173.47 Session Name (s): - Connection Information (c): IN IP4 134.2.173.47 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 134.2.173.47 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8002 RTP/AVP 98 97 8 0 3 101 Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute (a): ptime:20 * [ACK]: Session Initiation Protocol Request-Line: ACK sip:[EMAIL PROTECTED] SIP/2.0 Message Header Record-Route: Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.2 Via: SIP/2.0/UDP
