Re: [Sip-implementors] Sip From header without user part
Hi Paul, Thank you very much, I got your point. BR///Rakesh On Thu, Aug 4, 2022 at 10:28 PM Paul Kyzivat wrote: > On 8/4/22 11:09 AM, Rakesh wrote: > > Hi Paul, > > > > Thanks for your response. > > Quoting your statement "But it makes no sense to send this unless there > > was a matching prior sip request with the same sip URI." > > > > If I understood correctly the earlier request prior to CANCEL is > > normally a sip INVITE. And in case of INVITE has been sent with the such > > format in FROM header then further requests like CANCEL can send it else > > not. > > > > Do we have any reference on RFC that any SIP entity should not send sip > > From header as like on CANCEL if INVITE has not sent with that way? > > Spend some time understanding section 9 of RFC 3261. > > It doesn't say it is incorrect to send a CANCEL without a prior matching > request. But it specifies what the receiver of the CANCEL should do - > that it should send a 481 response. > > From what little you have said about the situation it sounds like this > may have been sent as part of a test. If so the sender may intentionally > be generating error cases to see if your implementation responds to them > as it should. > > Thanks, > Paul > > > BR///Rakesh > > > > On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat > <mailto:pkyzi...@alum.mit.edu>> wrote: > > > > On 8/4/22 8:11 AM, Rakesh wrote: > > > Hi Team, > > > > > > I could see in a sip CANCEL message From Header as below > > > > > > From: "test" > <http://ims.test.in>>;tag=3bbb9483d215d830c635372f8f181929 > > > > > > is this correct? > > > > Just looking at this, without regard for context, it is valid syntax. > > (The userinfo portion of the sip URI is optional.) > > > > But it makes no sense to send this unless there was a matching prior > > sip > > request with the same sip URI. > > > > Each domain is free to define the userinfo portion of its sip URIs > > as it > > sees fit. This includes whether to support URIs with no userinfo. You > > might want to consult an administrator for ims.test.in > > <http://ims.test.in>. > > > > Thanks, > > Paul > > > > > Normally the From header is sip:user@domain > > > > > > As per ABNF grammar, the above one is also should not be an issue > > as From > > > header but could let me know if I misinterpreted the ABNF grammar? > > > > > > BR///Rakesh > > > ___ > > > Sip-implementors mailing list > > > Sip-implementors@lists.cs.columbia.edu > > <mailto:Sip-implementors@lists.cs.columbia.edu> > > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > <https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors> > > > > ___ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > <mailto:Sip-implementors@lists.cs.columbia.edu> > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > <https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors> > > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Sip From header without user part
Hi Paul, Thanks for your response. Quoting your statement "But it makes no sense to send this unless there was a matching prior sip request with the same sip URI." If I understood correctly the earlier request prior to CANCEL is normally a sip INVITE. And in case of INVITE has been sent with the such format in FROM header then further requests like CANCEL can send it else not. Do we have any reference on RFC that any SIP entity should not send sip >From header as like on CANCEL if INVITE has not sent with that way? BR///Rakesh On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat wrote: > On 8/4/22 8:11 AM, Rakesh wrote: > > Hi Team, > > > > I could see in a sip CANCEL message From Header as below > > > > From: "test" ;tag=3bbb9483d215d830c635372f8f181929 > > > > is this correct? > > Just looking at this, without regard for context, it is valid syntax. > (The userinfo portion of the sip URI is optional.) > > But it makes no sense to send this unless there was a matching prior sip > request with the same sip URI. > > Each domain is free to define the userinfo portion of its sip URIs as it > sees fit. This includes whether to support URIs with no userinfo. You > might want to consult an administrator for ims.test.in. > > Thanks, > Paul > > > Normally the From header is sip:user@domain > > > > As per ABNF grammar, the above one is also should not be an issue as From > > header but could let me know if I misinterpreted the ABNF grammar? > > > > BR///Rakesh > > ___ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Sip From header without user part
Hi Team, I could see in a sip CANCEL message From Header as below From: "test" ;tag=3bbb9483d215d830c635372f8f181929 is this correct? Normally the From header is sip:user@domain As per ABNF grammar, the above one is also should not be an issue as From header but could let me know if I misinterpreted the ABNF grammar? BR///Rakesh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header
Sorry typo. "ff" I mean. BR/// Rakesh Kumar Mohanty On Fri, Feb 8, 2019 at 1:12 PM Rakesh wrote: > Hi Paul, > Thank you very much. > Another think I am thinking is FF is also not valid as per RFC 3261 it is > UTF-8 Character set. > Am I correct in understanding ? > > BR/// > > Rakesh Kumar Mohanty > > > On Thu, Feb 7, 2019 at 11:07 PM Paul Kyzivat > wrote: > >> Rakesh privately asked me why this doesn't conform to the ABNF of a sip >> message. I'm replying to the list for the benefit of others. >> >> Here is some of the relevant ABNF: >> >> SIP-message= Request / Response >> Request= Request-Line >>*( message-header ) >>CRLF >>[ message-body ] >> Request-Line = Method SP Request-URI SP SIP-Version CRLF >> Method= INVITEm / ACKm / OPTIONSm / BYEm >> / CANCELm / REGISTERm >> / extension-method >> extension-method = token >> Response = Status-Line >> *( message-header ) >> CRLF >> [ message-body ] >> Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF >> SIP-Version= "SIP" "/" 1*DIGIT "." 1*DIGIT >> token = 1*(alphanum / "-" / "." / "!" / "%" / "*" >> / "_" / "+" / "`" / "'" / "~" ) >> >> Examining this you can see that a message must start with one of the >> following: >> >> - a token - a method name >> - "SIP/" - beginning a sip version >> >> What you show is neither of those, so it isn't valid sip. >> >> Over UDP every packet must start with a message. Over TCP, messages >> immediately follow one another. Every request or response ends with CRLF >> followed by an optional body. You must parse Content-Length in order to >> skip over the body (which may also contain CRLF). >> >> If you encounter something that doesn't parse as a message with TCP >> input you have to close the connection without parsing any more, or else >> use a heuristic to skip over stuff until you find what seems to be the >> beginning of a new message. >> >> Thanks, >> Paul >> >> >>> *ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * >> > >> > > 0010 * ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff* >> > >> > > 0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> > > >> > > 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> > >> > > 0020 ff ff ff ff ff ff ff ff ff ff ff 58 2d 42 72 6f >> > ÿÿÿX-xro >> > > 0030 61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74 : net >> > > 0040 77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 >> > work-address="si >> > > 0050 70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d >> > p:@xx.yyy.net <mailto:p...@xx.yyy.net> >> > > 0070 74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 >> > t;user=phone";us >> > > 0080 65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 >> > er-id="" >> > > 0090 40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e @xx.yyy. >> > > 00a0 6e 65 74 22 0d 0a net".. >> > > ÿÿÿX-xro >> > > 0030 61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74 : net >> > > 0040 77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 >> > work-address="si >> > > 0050 70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d >> > p:@xx.yyy.net <mailto:p...@xx.yyy.net> >> > > 0070 74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 >> > t;user=phone";us >> > > 0080 65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 >> > er-id="" >> > > 0090 40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e @xx.yyy. >> > > 00a0 6e 65 74 22 0d 0a net".. >> > > >> > > [image: image.png] >> > > >> > > BR/// >> > >
Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header
Hi Paul, Thank you very much. Another think I am thinking is FF is also not valid as per RFC 3261 it is UTF-8 Character set. Am I correct in understanding ? BR/// Rakesh Kumar Mohanty On Thu, Feb 7, 2019 at 11:07 PM Paul Kyzivat wrote: > Rakesh privately asked me why this doesn't conform to the ABNF of a sip > message. I'm replying to the list for the benefit of others. > > Here is some of the relevant ABNF: > > SIP-message= Request / Response > Request= Request-Line >*( message-header ) >CRLF >[ message-body ] > Request-Line = Method SP Request-URI SP SIP-Version CRLF > Method= INVITEm / ACKm / OPTIONSm / BYEm > / CANCELm / REGISTERm > / extension-method > extension-method = token > Response = Status-Line > *( message-header ) > CRLF > [ message-body ] > Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF > SIP-Version= "SIP" "/" 1*DIGIT "." 1*DIGIT > token = 1*(alphanum / "-" / "." / "!" / "%" / "*" > / "_" / "+" / "`" / "'" / "~" ) > > Examining this you can see that a message must start with one of the > following: > > - a token - a method name > - "SIP/" - beginning a sip version > > What you show is neither of those, so it isn't valid sip. > > Over UDP every packet must start with a message. Over TCP, messages > immediately follow one another. Every request or response ends with CRLF > followed by an optional body. You must parse Content-Length in order to > skip over the body (which may also contain CRLF). > > If you encounter something that doesn't parse as a message with TCP > input you have to close the connection without parsing any more, or else > use a heuristic to skip over stuff until you find what seems to be the > beginning of a new message. > > Thanks, > Paul > > >> *ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * > > > > > 0010 * ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff* > > > > > 0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > > > 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > > 0020 ff ff ff ff ff ff ff ff ff ff ff 58 2d 42 72 6f > > ÿÿÿX-xro > > > 0030 61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74 : net > > > 0040 77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 > > work-address="si > > > 0050 70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d > > p:@xx.yyy.net <mailto:p...@xx.yyy.net> > > > 0070 74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 > > t;user=phone";us > > > 0080 65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 > > er-id="" > > > 0090 40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e @xx.yyy. > > > 00a0 6e 65 74 22 0d 0a net".. > > > ÿÿÿX-xro > > > 0030 61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74 : net > > > 0040 77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 > > work-address="si > > > 0050 70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d > > p:@xx.yyy.net <mailto:p...@xx.yyy.net> > > > 0070 74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 > > t;user=phone";us > > > 0080 65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 > > er-id="" > > > 0090 40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e @xx.yyy. > > > 00a0 6e 65 74 22 0d 0a net".. > > > > > > [image: image.png] > > > > > > BR/// > > > > > > Rakesh Kumar Mohanty > > > > > > > > > On Wed, Feb 6, 2019 at 3:21 PM Rakesh > <mailto:rak...@gmail.com>> wrote: > > > > > >> Hi Expert, > > >> > > >> Can I just know on INVITE request if I get the below characters > > then is > > >> it OK as per ABNF grammar? Please note I am not asking about > > the header >
Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header
Hi, Further to add to the last this is what I am looking for the bold part *ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 0010 * ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff* 0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0020 ff ff ff ff ff ff ff ff ff ff ff 58 2d 42 72 6f ÿÿÿX-xro 0030 61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74 : net 0040 77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 work-address="si 0050 70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d p:@xx.yyy.net 0070 74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 t;user=phone";us 0080 65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 er-id="" 0090 40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e @xx.yyy. 00a0 6e 65 74 22 0d 0a net".. ÿÿÿX-xro 0030 61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74 : net 0040 77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 work-address="si 0050 70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d p:@xx.yyy.net 0070 74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 t;user=phone";us 0080 65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 er-id="" 0090 40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e @xx.yyy. 00a0 6e 65 74 22 0d 0a net".. [image: image.png] BR/// Rakesh Kumar Mohanty On Wed, Feb 6, 2019 at 3:21 PM Rakesh wrote: > Hi Expert, > > Can I just know on INVITE request if I get the below characters then is > it OK as per ABNF grammar? Please note I am not asking about the header > rather I need to know the correctness of the character that has appeared on > INVITE request. > > > [truncated]\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\37 > Expert Info (Note/Undecoded): Unrecognised SIP header > (���) > > [image: image.png] > [image: image.png] > > BR/// > > Rakesh Kumar Mohanty > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header
Hi Expert, Can I just know on INVITE request if I get the below characters then is it OK as per ABNF grammar? Please note I am not asking about the header rather I need to know the correctness of the character that has appeared on INVITE request. [truncated]\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\37 Expert Info (Note/Undecoded): Unrecognised SIP header (���) [image: image.png] [image: image.png] BR/// Rakesh Kumar Mohanty ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Codec Negotiation issue
Hi Asim, It is not answer to my question since the section that you refer is not answering my above question. I am aware of this already. Thanks. I need to know any specific order or priority to handle the coded and why not all codec listed is not send back in answer as both A and B support all the EVS, AMR WB, AMR NB? I think you have not follow the scenario mentioned above. 2.6 <https://tools.ietf.org/html/rfc4317#section-2.6>. Audio Only 1 Alice wishes to establish an audio session with Bob using either PCMU codec or iLBC codec with RFC2833 <https://tools.ietf.org/html/rfc2833> tones, but not both at the same time. The offer contains these two media streams. Bob declines the first one and accepts the second one. If both media streams had been accepted, Alice would have sent a second declining one of the streams, as shown in Section 4.3 <https://tools.ietf.org/html/rfc4317#section-4.3>. Johnston & SparksInformational [Page 8] -- <https://tools.ietf.org/html/rfc4317#page-9>RFC 4317 <https://tools.ietf.org/html/rfc4317> SDP Offer/Answer Examples December 2005 [Offer] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=audio 51372 RTP/AVP 97 101 a=rtpmap:97 iLBC/8000 a=rtpmap:101 telephone-event/8000 [Answer] v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=audio 49170 RTP/AVP 97 101 a=rtpmap:97 iLBC/8000 a=rtpmap:101 telephone-event/8000 BR/// Rakesh Kumar Mohanty On Thu, Feb 22, 2018 at 2:25 PM, Asim Sulaiman wrote: > Please have a look to RFC 4317 and Section 2 > > Regards, > Asim Sulaiman > > From: sip-implementors-boun...@lists.cs.columbia.edu [ > sip-implementors-boun...@lists.cs.columbia.edu] on behalf of Rakesh [ > rak...@gmail.com] > Sent: Thursday, February 22, 2018 12:34 PM > To: sip-implementors > Subject: [Sip-implementors] Codec Negotiation issue > > Hi Expert, > > I have a scenario here can anyone help me to undrstand is the behaviour is > correct on both cases? > > FIRST CASE: > • User A calls User B > • Negoziation for EVS codec > • User A put in hold User B > • REINVITE from User A, contains sendonly, with only EVS (codec negotiated > and used). > • REINVITE arrives to User B, it contains sendonly with all the codecs > handled by volte network in the following order: EVS, AMR WB, AMR NB. > • User B answer with 200 OK just with EVS and the call has not any call > quality issue. > > SECOND CASE: > • User B put in Hold User A > • User B sends REINVITE with sendonly containing only EVS, > • REINVITE arrives to User A with sendonly and it contains all the VoLTE > codecsin the following order: AMR WB, EVS, AMR NB. > • User A answer with 200 OK recvonly that contains only AMR-WB because is > the first in the list and the call quality has degraded > > So is the codec negotiation in both cases OK I am asking since in one case > call quality is OK and in other case call quality is NOK? > > Any RFC standard or reference to understand completely the codec order and > priority to handle? > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > Disclaimer : > This e-mail message may contain confidential, proprietary or legally > privileged information. It should not be used by anyone who is not the > original intended recipient. If you have erroneously received this message, > please delete it immediately and notify the sender. The recipient > acknowledges that EMIRCOM, as the case may be, are unable to exercise > control or ensure or guarantee the integrity of/over the contents of the > information contained in e-mail transmissions and further acknowledges that > any views expressed in this message are those of the individual sender and > no binding nature of the message shall be implied or assumed unless the > sender does so expressly with due authority of EMIRCOM. Before opening any > attachments please check them for viruses and defects. > > > > Disclaimer : > This e-mail message may contain confidential, proprietary or legally > privileged information. It should not be used by anyone who is not the > original intended recipient. If you have erroneously re
[Sip-implementors] Codec Negotiation issue
Hi Expert, I have a scenario here can anyone help me to undrstand is the behaviour is correct on both cases? FIRST CASE: • User A calls User B • Negoziation for EVS codec • User A put in hold User B • REINVITE from User A, contains sendonly, with only EVS (codec negotiated and used). • REINVITE arrives to User B, it contains sendonly with all the codecs handled by volte network in the following order: EVS, AMR WB, AMR NB. • User B answer with 200 OK just with EVS and the call has not any call quality issue. SECOND CASE: • User B put in Hold User A • User B sends REINVITE with sendonly containing only EVS, • REINVITE arrives to User A with sendonly and it contains all the VoLTE codecsin the following order: AMR WB, EVS, AMR NB. • User A answer with 200 OK recvonly that contains only AMR-WB because is the first in the list and the call quality has degraded So is the codec negotiation in both cases OK I am asking since in one case call quality is OK and in other case call quality is NOK? Any RFC standard or reference to understand completely the codec order and priority to handle? ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Offerless Re-INVITE
*Hi ,* *Can any one tell me what will be the codec can be sent on 200OK in below ?* *Is this the one that support by UE or the Supported codec by Proxy ?* *UA Proxy *>>* -> *>>* (INVITE SDP: codecs 0 18 101) *>>>>* <-- *>>* (200 OK SDP: codecs 0 101) *>>>>* > *>>* ACK (no SDP) *>>>>>>* <--- *>>* (re-INVITE no SDP) *>>>>* --> *>> * (200 OK SDP: codecs ?)* *As per RFC,**RFC 6337 section 5.2.5: *>>* "When the new offer is sent in response to an offerless (re-)INVITE, it *>* should be constructed according to the General Principle for Constructing *>* Offers and Answers (Section 5.1 ): all codecs the UA is currently willing *>* and able to use should be included, not just the ones that were negotiated *>* by previous offer/answer exchanges. The same is true for media types -- *>* so if UA A initially offered audio and video to UA B, and they end up with *>* only audio, and UA B sends an offerless (re-)INVITE to UA A, A's resulting *>* offer should most likely re-attempt video, by reusing the zeroed "m=" line *> * used previously."* *SO I didn't able to understand this "* *all codecs the UA is currently willing > and able to use should be included, not just the ones that were negotiated > by previous offer/answer exchanges."* BR/// Rakesh Kumar Mohanty ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Contact header URI comaprision
Hi Paul, Thanks now it's clear my idea about the behaviour. You are true on your feedback. BR/// Rakesh Kumar Mohanty On Tue, Jul 18, 2017 at 9:01 PM, Paul Kyzivat wrote: > On 7/18/17 4:00 AM, Rakesh wrote: > >> Hi Paul, >> >> Thanks for the update. >> >> So the 200OK in step 4 Registrar should respond with only one contact >> header >> Contact: ""mailto:sip%3A%2B1689998@178.2 >> 1.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200 >> ? >> > > Yes. > > But since there is a difference in contact so it has to be overwritten >> with the previous contact of step1? >> > > I don't understand what you are trying to say with this last sentence. > > In my earlier reply I quoted the wrong section of 3261. (It was the > section for clients, not registrars.) The applicable portion is from steps > 7&8 of section 10.3: > > 7. ... > For each address, the registrar then searches the list of > current bindings using the URI comparison rules. If the > binding does not exist, it is tentatively added. If the > binding does exist, the registrar checks the Call-ID value. If > the Call-ID value in the existing binding differs from the > Call-ID value in the request, the binding MUST be removed if > the expiration time is zero and updated otherwise. If they are > the same, the registrar compares the CSeq value. If the value > is higher than that of the existing binding, it MUST update or > remove the binding as above. If not, the update MUST be > aborted and the request fails. > ... > > 8. The registrar returns a 200 (OK) response. The response MUST > contain Contact header field values enumerating all current > bindings. ... > > Hence it is clear that new contact value must be recorded by the registrar > and returned in the response. > > Currently, the Registrar is working in the below way, >> >> Contact: ""> ssn;srti=s1_2>;expires=0 >> >> Contact: ""> ssn;TRC=-;srti=s1_2>;expires=7200 >> >> Since the both the contact are same as per 19.1.4 it is only keeping the >> contact header value of the second REGISTER request. >> > > Again I don't understand your point. The response enumerate all *current* > bindings. Because it is returning two URIs it must think that they are both > current. Yet they compare equal so the registrar should have replaced the > old one with the new one, and hence there should only be one current > contact - the new one. > > Thanks, > Paul > > Can you please clarify? >> >> BR/// >> >> Rakesh Kumar Mohanty >> >> >> On Mon, Jul 17, 2017 at 10:13 PM, Paul Kyzivat > <mailto:pkyzi...@alum.mit.edu>> wrote: >> >> On 7/17/17 11:08 AM, Rakesh wrote: >> >> Hi Expert, >> >> Now I got the full picture for the problem. >> >> SIP Registrar behavior for the URI contact matching >> >> 1) REGISTER request with belwo contact send to Registrar >> >> Contact: ""> <mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt >> =8ea2_16;ssn;srti=s1_2>;expires=7200 >> >> 2) Registrar sent 200OK with below contact >> >> Contact: ""> >> @178.21.49.29 >> <mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt >> =8ea2_16;ssn;srti=s1_2>;expires=7200 >> >> 3) Now there is another REGISTER request send to the Registrar >> in contact with additional parameter mentioned below >> >> Contact: ""> <mailto:sip%3A%2B1689998@178.21.49.29>:3694;transport=udp;Hp >> t=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200 >> >> 4) Then Registrar sent 200OK response with below contact >> headers. Where the Initial contact has value expires= 0 >> >> Contact: ""> >> @178.21.49.29 >> <mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt >> =8ea2_16;ssn;srti=s1_2>;expires=0 >> >> Contact: ""> <mailto:sip%3A%2B1689998@178.21.49.29>:3694;transport=udp;Hp >> t=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200 >> >> >> >> So is it a valid behavior from Registrar server? Which leads the >
Re: [Sip-implementors] Contact header URI comaprision
Hi Paul, Thanks for the update. So the 200OK in step 4 Registrar should respond with only one contact header Contact: "":3 694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200 ? But since there is a difference in contact so it has to be overwritten with the previous contact of step1? Currently, the Registrar is working in the below way, Contact: "";expires=0 Contact: "";expires=7200 Since the both the contact are same as per 19.1.4 it is only keeping the contact header value of the second REGISTER request. Can you please clarify? BR/// Rakesh Kumar Mohanty On Mon, Jul 17, 2017 at 10:13 PM, Paul Kyzivat wrote: > On 7/17/17 11:08 AM, Rakesh wrote: > >> Hi Expert, >> >> Now I got the full picture for the problem. >> >> SIP Registrar behavior for the URI contact matching >> >> 1) REGISTER request with belwo contact send to Registrar >> >> Contact: ""> ssn;srti=s1_2>;expires=7200 >> >> 2) Registrar sent 200OK with below contact >> >> Contact: ""> >> @178.21.49.29 :36 >> 94;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=7200 >> >> 3) Now there is another REGISTER request send to the Registrar in contact >> with additional parameter mentioned below >> >> Contact: "":3 >> 694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti >> =s1_2>;expires=7200 >> >> 4) Then Registrar sent 200OK response with below contact headers. Where >> the Initial contact has value expires= 0 >> >> Contact: ""> >> @178.21.49.29 :36 >> 94;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0 >> >> Contact: "":3 >> 694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti >> =s1_2>;expires=7200 >> >> >> So is it a valid behavior from Registrar server? Which leads the earlier >> post asked for contact matching. >> > > From 3261: > > 10.2.4 Refreshing Bindings > >Each UA is responsible for refreshing the bindings that it has >previously established. A UA SHOULD NOT refresh bindings set up by >other UAs. > >The 200 (OK) response from the registrar contains a list of Contact >fields enumerating all current bindings. The UA compares each >contact address to see if it created the contact address, using >comparison rules in Section 19.1.4. If so, it updates the expiration >time interval according to the expires parameter or, if absent, the >Expires field value. The UA then issues a REGISTER request for each >of its bindings before the expiration interval has elapsed. It MAY >combine several updates into one REGISTER request. > >A UA SHOULD use the same Call-ID for all registrations during a >single boot cycle. Registration refreshes SHOULD be sent to the same >network address as the original registration, unless redirected. > > We have already discussed those comparison rules. So the second REGISTER > should qualify as a refresh. But apparently the registrar is not > recognizing it as such and instead is treating it as an additional > registration. That appears to be a bug in the registrar. > > Thanks, > Paul > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Contact header URI comaprision
Hi Expert, Now I got the full picture for the problem. SIP Registrar behavior for the URI contact matching 1) REGISTER request with belwo contact send to Registrar Contact: "";expires=7200 2) Registrar sent 200OK with below contact Contact: "";expires=7200 3) Now there is another REGISTER request send to the Registrar in contact with additional parameter mentioned below Contact: "";expires=7200 4) Then Registrar sent 200OK response with below contact headers. Where the Initial contact has value expires= 0 Contact: "";expires=0 Contact: "";expires=7200 So is it a valid behavior from Registrar server? Which leads the earlier post asked for contact matching. BR/// Rakesh Kumar Mohanty On Fri, Jul 14, 2017 at 8:17 PM, Paul Kyzivat wrote: > On 7/14/17 3:53 AM, Rakesh wrote: > >> Hi Expert, >> >> I am facing an issue on which the contact URI comparison has happened and >> it fails due to the TRC parameter not in order which I guess so far. >> >> Contact: "" > ;srti=s1_2> >> Contact: "" > ;TRC=-;srti=s1_2> >> >> I saw in RFC 3261 19.1.4 URI Comparison >> >> URI uri-parameter components are compared as follows: >> > > ... > > The following: > > - All other uri-parameters appearing in only one URI are >> ignored when comparing the URIs. >> > > is the operative rule here. > > So does it mean the correct order should be given below where the TRC >> parameter should be put at the last? >> >> Contact: "" > ;srti=s1_2> >> Contact: "" > ;srti=s1_2;TRC=-> >> > > What leads you to this conclusion? Parameter order is never relevant. > > Thanks, > Paul > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Contact header URI comaprision
Hi Expert, I found the problem. Thanks for making comment on my request. BR/// Rakesh Kumar Mohanty On Sat, Jul 15, 2017 at 7:36 AM, Dale R. Worley wrote: > Paul Kyzivat writes: > >> Contact: "" > >> > >> Contact: "" > >> ssn;srti=s1_2;TRC=-> > > > > What leads you to this conclusion? Parameter order is never relevant. > > Specifically, a little earlier in section 19.1.4 is: > > o The ordering of parameters and header fields is not significant > in comparing SIP and SIPS URIs. > > >> I am facing an issue on which the contact URI comparison has happened > and > >> it fails due to the TRC parameter not in order which I guess so far. > > By the rules of 3261, these two URIs are equivalent. > > Dale > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Contact header URI comaprision
Hi Expert, I am facing an issue on which the contact URI comparison has happened and it fails due to the TRC parameter not in order which I guess so far. Contact: "" Contact: "" I saw in RFC 3261 19.1.4 URI Comparison URI uri-parameter components are compared as follows: - Any uri-parameter appearing in both URIs must match. - A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it contains the default value. - A URI that includes an maddr parameter will not match a URI that contains no maddr parameter. - All other uri-parameters appearing in only one URI are ignored when comparing the URIs. Rosenberg, et. al. Standards Track [Page 154] RFC 3261SIP: Session Initiation Protocol June 2002 URI header components are never ignored. Any present header component MUST be present in both URIs and match for the URIs to match. The matching rules are defined for each header field in Section 20. And Note that equality is not transitive: sip:ca...@chicago.com and sip:ca...@chicago.com;security=on are equivalent sip:ca...@chicago.com and sip:ca...@chicago.com;security=off are equivalent Rosenberg, et. al. Standards Track [Page 155] RFC 3261SIP: Session Initiation Protocol June 2002 sip:ca...@chicago.com;security=on and sip:ca...@chicago.com;security=off are not equivalent So does it mean the correct order should be given below where the TRC parameter should be put at the last? Contact: "" Contact: "" BR/// Rakesh Kumar Mohanty ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] FAX T38 issue
Hi Jan, Thanks a lot. *BR///* *Rakesh Kumar Mohanty* On Wed, Jun 14, 2017 at 11:28 PM, Jan Bollen wrote: > Hello Rakesh, > > You will find the ITU-T.38 standard on ITU's website: > http://www.itu.int/rec/T-REC-T.38/en and select the version that has "in > force" as status. > > Cheers, > Jan > > > On 14/06/2017 9:52, Rakesh wrote: > > Hi Jan, > > Sorry missed one more thing to ask. As you have mentioned the standard can > you please share me the doc for that? I am not getting from Google since > the search shows too many stuff. > > *BR///* > > *Rakesh Kumar Mohanty* > > On Wed, Jun 14, 2017 at 1:19 PM, Rakesh wrote: > >> Hi All, >> >> @Jan Many thanks to your answer. >> >> Thanks all for the feedback. >> >> @Sampat can you let me know from which reference you have mentioned that >> it will be treated as Error? Moreover, I am not asking for any Propriety >> node behavior. I just want to know the communication between the Media >> Controler and Media Gateway haveing the observed behavior anything relevant >> standard to answer that the SDP should/must contain the xyz... media >> attribute. >> >> >> *BR///* >> >> *Rakesh Kumar Mohanty* >> >> On Sat, Jun 10, 2017 at 12:22 AM, Jan Bollen < >> jan.bol...@scarlet.be> wrote: >> >>> Hi Rakesh, >>> >>> Looking at section D.2.3.1 of the ITU_T T.38 standard, I have the >>> impression that at least the T38Error correction is necessary when udptl as >>> transport is used, because it is _not_ marked as optional... >>> >>> quote: >>> *UDPTL Options* >>> *Maximum Buffer Size* >>> * Att-field=T38FaxMaxBuffer* >>> * Att-value = 1*(DIGIT)* >>> * ;optional* >>> *Maximum Datagram Size* >>> * Att-field=T38FaxMaxDatagram* >>> * Att-value = 1*(DIGIT)* >>> * ;optional* >>> >>> >>> *Error Correction Att-field=T38FaxUdpEC Att-value = t38UDPFEC | >>> t38UDPRedundancy* >>> *T38VendorInfo* >>> * Att-field=T38VendorInfo* >>> * Att-value = t35country-code SP t35extention SP manufacturer-code* >>> * t35country-code = 1*(DIGIT)* >>> * t35extension = 1*(DIGIT)* >>> * manufacturer-code = 1*(DIGIT)* >>> *;optional* >>> * ;0 to 255 for t35country-code and t35extension* >>> * ;t35country-code is defined in T.35 Annex A.* >>> * ;t35extension is defined in T.35 Annex B* >>> * ;The value of "manufacturer-code" is assigned nationally* >>> unquote >>> >>> kind regards, >>> Jan >>> >>> >>> >> > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] FAX T38 issue
Hi Jan, Sorry missed one more thing to ask. As you have mentioned the standard can you please share me the doc for that? I am not getting from Google since the search shows too many stuff. *BR///* *Rakesh Kumar Mohanty* On Wed, Jun 14, 2017 at 1:19 PM, Rakesh wrote: > Hi All, > > @Jan Many thanks to your answer. > > Thanks all for the feedback. > > @Sampat can you let me know from which reference you have mentioned that > it will be treated as Error? Moreover, I am not asking for any Propriety > node behavior. I just want to know the communication between the Media > Controler and Media Gateway haveing the observed behavior anything relevant > standard to answer that the SDP should/must contain the xyz... media > attribute. > > > *BR///* > > *Rakesh Kumar Mohanty* > > On Sat, Jun 10, 2017 at 12:22 AM, Jan Bollen > wrote: > >> Hi Rakesh, >> >> Looking at section D.2.3.1 of the ITU_T T.38 standard, I have the >> impression that at least the T38Error correction is necessary when udptl as >> transport is used, because it is _not_ marked as optional... >> >> quote: >> *UDPTL Options* >> *Maximum Buffer Size* >> * Att-field=T38FaxMaxBuffer* >> * Att-value = 1*(DIGIT)* >> * ;optional* >> *Maximum Datagram Size* >> * Att-field=T38FaxMaxDatagram* >> * Att-value = 1*(DIGIT)* >> * ;optional* >> >> >> *Error Correction Att-field=T38FaxUdpEC Att-value = t38UDPFEC | >> t38UDPRedundancy* >> *T38VendorInfo* >> * Att-field=T38VendorInfo* >> * Att-value = t35country-code SP t35extention SP manufacturer-code* >> * t35country-code = 1*(DIGIT)* >> * t35extension = 1*(DIGIT)* >> * manufacturer-code = 1*(DIGIT)* >> *;optional* >> * ;0 to 255 for t35country-code and t35extension* >> * ;t35country-code is defined in T.35 Annex A.* >> * ;t35extension is defined in T.35 Annex B* >> * ;The value of "manufacturer-code" is assigned nationally* >> unquote >> >> kind regards, >> Jan >> >> >> > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] FAX T38 issue
Hi All, @Jan Many thanks to your answer. Thanks all for the feedback. @Sampat can you let me know from which reference you have mentioned that it will be treated as Error? Moreover, I am not asking for any Propriety node behavior. I just want to know the communication between the Media Controler and Media Gateway haveing the observed behavior anything relevant standard to answer that the SDP should/must contain the xyz... media attribute. *BR///* *Rakesh Kumar Mohanty* On Sat, Jun 10, 2017 at 12:22 AM, Jan Bollen wrote: > Hi Rakesh, > > Looking at section D.2.3.1 of the ITU_T T.38 standard, I have the > impression that at least the T38Error correction is necessary when udptl as > transport is used, because it is _not_ marked as optional... > > quote: > *UDPTL Options* > *Maximum Buffer Size* > * Att-field=T38FaxMaxBuffer* > * Att-value = 1*(DIGIT)* > * ;optional* > *Maximum Datagram Size* > * Att-field=T38FaxMaxDatagram* > * Att-value = 1*(DIGIT)* > * ;optional* > > > *Error Correction Att-field=T38FaxUdpEC Att-value = t38UDPFEC | > t38UDPRedundancy* > *T38VendorInfo* > * Att-field=T38VendorInfo* > * Att-value = t35country-code SP t35extention SP manufacturer-code* > * t35country-code = 1*(DIGIT)* > * t35extension = 1*(DIGIT)* > * manufacturer-code = 1*(DIGIT)* > *;optional* > * ;0 to 255 for t35country-code and t35extension* > * ;t35country-code is defined in T.35 Annex A.* > * ;t35extension is defined in T.35 Annex B* > * ;The value of "manufacturer-code" is assigned nationally* > unquote > > kind regards, > Jan > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] FAX T38 issue
HI Jan/Expert, Sorry.Tthis is the SDP in Successful, t=0 0 m=image 52702 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxUdpEC:t38UDPRedundancy And in Unsuccessful case, t=0 0 m=image 50040 udptl t38 a=T38FaxVersion:0 *BR///* *Rakesh Kumar Mohanty* On Thu, Jun 8, 2017 at 9:24 PM, Jan Bollen wrote: > > Hi, > > The "media attribute" image was apparently eliminated from the message, > so I can't comment on it. Meanwhile, you might want to have a look at the > free-of-chare T.38 standard at http://www.itu.int/rec/T-REC-T.38/en > > kind regards, > Jan > > On 8/06/2017 17:44, Rakesh wrote: > > Hi Expert, > > Is the below media attribute is mandatory for FAX t38 call? > > [image: Inline image 1] > > Any RFC to mentioned the FAX t38 standard call flow? > > I am getting "488 not acceptable" failure response while sending a fax > INVITE with the media attribute is like below, > > [image: Inline image 2] > > *BR///* > > *Rakesh Kumar Mohanty* > > > > > ___ > Sip-implementors mailing > listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] FAX T38 issue
Hi Expert, Is the below media attribute is mandatory for FAX t38 call? [image: Inline image 1] Any RFC to mentioned the FAX t38 standard call flow? I am getting "488 not acceptable" failure response while sending a fax INVITE with the media attribute is like below, [image: Inline image 2] *BR///* *Rakesh Kumar Mohanty* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Request for RFC section for UE behavior
Dear Expert, Can UE reuse the same Call-ID, From tag and CSeq number, as it had used for another INVITE which got terminated by 408, or it should really update the Call-ID and/or From tag, to send the new INVITE request? Is there any RFC 3261 section mentioned for this? *Best Regards* *Rakesh Kumar Mohanty* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SIP REGISTRTION INFO
Hi Paul, It's 401 unauthorized error. On 06-Jan-2017 11:15 PM, "Paul Kyzivat" wrote: Rakesh, You don't say, at step 8, what code is the UAS using to reject the new register request? Thanks, Paul On 1/6/17 7:50 AM, Rakesh wrote: > Hi Expert, > > My understanding is this please correct if I am wrong, > > Step 1) UE sent REGISTER with CSequence Number: 1804289384 and Call-ID: > 28335007c4047a42 > > Step 2) 401 with CSequence Number: 1804289384 and Call-ID: > 28335007c4047a42 > > Step 3) After challenge UE sent the REGISTER with CSequence Number: > 1804289385 and Call-ID: 28335007c4047a42 > > Step 4 ) 200OK with same CSequence Number: 1804289385 and Call-ID: > 28335007c4047a42which is expected . > > > > Call Continue... Everything is OK > > > > Step 5) UE sent DE-REGISTRATION with CSequence Number: 1804289386 and > Call-ID: 28335007c4047a42 > > Step 6) 200OK for DE-REGISTRATION with same with CSequence Number: > 1804289386 and Call-ID: 28335007c4047a42 which is also expected . Here all > contacts are removed (all AOR binding clear) > > > > Step 7) UE now sent another fresh REGISTER request with CSequence Number: > 1804289384 and Call-ID: ee74e9624ebe1844 > > Step 8) > UAS > is now rejecting continuously the REGISTER. > > > > So the question is in Step 7 ) the call id now changed to Call-ID: > ee74e9624ebe1844 and as per RFC 3261 it says , > > > 10.3 <https://tools.ietf.org/html/rfc3261#section-10.3> Processing > REGISTER > > Requests > > Point 7. > > > > For each address, the registrar then searches the list of > > current bindings using the URI comparison rules. If the > > binding does not exist, it is tentatively added. *If the* > > * binding does exist, the registrar checks the Call-ID value. If* > > * the Call-ID value in the existing binding differs from the* > > * Call-ID value in the request, the binding MUST be removed if* > > * the expiration time is zero and updated otherwise.* If they are > > > the same, the registrar compares the CSeq value. If the value > > is higher than that of the existing binding, it MUST update or > > remove the binding as above. If not, the update MUST be > > aborted and the request fails. > > > > > In our case the Call-ID: ee74e9624ebe1844 value us differ from the previous > one so the UAS should update the binding and accept the REGISTER request > instead rejecting it with 401. > > *Best Regards* > > *Rakesh Kumar Mohanty* > > > > On Fri, Jan 6, 2017 at 4:44 PM, Mohit Soni > wrote: > > Hi Rakesh, >> >> Full trace of your scenario or at least the message body of the fresh >> REGISTER message sent from UE with new Call-ID may help figure out things. >> >> >> Regards, >> Mohit Soni >> >> On Fri, Jan 6, 2017 at 4:02 PM, Rakesh wrote: >> >> Hi Expert, >>> >>> I need one info for the following below SIP REGISTER scenario. >>> >>> Step 1) UE sent REGISTER with CSeq =1 CallID=11 >>> Step 2) 401 with CSeq =1 CallID=11 >>> Step 3) After challenge UE sent the REGISTER with CSeq =2 CallID=11 >>> Step 4 ) 200OK with same CSeq =2 CallID=11 which is expected . >>> >>> Call Continue... Everything is OK >>> >>> Step 5) UE sent DE-REGISTRATION with CSeq =3 CallID=11 >>> Step 6) 200OK for DE-REGISTRATION with same CSeq =3 CallID=11 which >>> is >>> expected . Here all contacts are removed (all AOR binding clear) >>> >>> Step 7) UE now sent another fresh REGISTER request with CSeq =1 >>> CallID=12 >>> >>> Step 8) UAS is now rejecting continuously the REGISTER. >>> >>> So the question is in Step 7 ) the call id now changed to 12 and as >>> per >>> RFC 3261 it says >>> >>> The first question is, >>> >>> It says 8.1.1.4 Call-ID >>> >>> >>>The Call-ID header field acts as a unique identifier to group together >>> a series of messages. It MUST be the same for all requests >>>and responses sent by either UA in a dialogue. >>> *It SHOULD be the same in each registration from a UA.* >>> >>> *Best Regards* >>> >>> *Rakesh Kumar Mohanty* >>> ___ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >>> >> >> ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SIP REGISTRTION INFO
HI Brett, Thanks for the response .. Have a nice day .. *Best Regards* *Rakesh Kumar Mohanty* On Fri, Jan 6, 2017 at 8:44 PM, Brett Tate wrote: > As mentioned based upon what you provided, the server returning 401 is > okay. The client just goes through the normal authentication process by > sending REGISTER with higher cseq and new Authorization based upon the > received 401. If the REGISTER continues to fail authentication (causing > 403 or another 401), it could be because of bad auth credentials or a bug > somewhere. > > > > *From:* Rakesh [mailto:rak...@gmail.com] > *Sent:* Friday, January 06, 2017 9:59 AM > > *To:* Brett Tate > *Subject:* Re: [Sip-implementors] SIP REGISTRTION INFO > > > > Hi Brett, > > > > Thanks for the response. So here the UAS should handle it instead > rejecting. > > My case the UE deregister is due to rebooted automatically and after that > UE not able to register . > > > > > *Best Regards* > > *Rakesh Kumar Mohanty* > > > > > > On Fri, Jan 6, 2017 at 7:46 PM, Brett Tate wrote: > > Hi, > > > > Yes; it can change Call-ID. If I recall correctly, much of the Call-ID > reuse stuff mentioned within RFC 3261 section 10 indicates “SHOULD” instead > of “MUST”. See RFC 3261 section 3 for where to look for meaning of > “SHOULD” and “MUST”. > > > > Since deregister removes the binding, I don’t recall if the working group > actually intended Call-ID to remain the same if deregister and then > register within the same boot cycle. > > > > RFC 3261 section 10.2: > > > > “Call-ID: All registrations from a UAC SHOULD use the same Call-ID > >header field value for registrations sent to a particular > >registrar. > > > >If the same client were to use different Call-ID values, a > >registrar could not detect whether a delayed REGISTER request > >might have arrived out of order.” > > > > RFC 3261 section 10.2.4: > > > > “A UA SHOULD use the same Call-ID for all registrations during a > >single boot cycle. Registration refreshes SHOULD be sent to the same > >network address as the original registration, unless redirected.” > > > > *From:* Rakesh [mailto:rak...@gmail.com] > *Sent:* Friday, January 06, 2017 8:48 AM > *To:* Brett Tate > *Subject:* Re: [Sip-implementors] SIP REGISTRTION INFO > > > > Hi Brett, > > > > Thanks for the confirmation .. My question is that can same UE change the > call ID for a new Register request? > > > > BR///Rakesh > > > *Best Regards* > > *Rakesh Kumar Mohanty* > > > > > > On Fri, Jan 6, 2017 at 6:33 PM, Brett Tate wrote: > > > In our case the Call-ID: ee74e9624ebe1844 value us > > differ from the previous one so the UAS should update > > the binding and accept the REGISTER request instead > > rejecting it with 401. > > 401 is associated with authentication. They have the right to generate > 401 if they want. For instance, they might want to change nonce. > > > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SIP REGISTRTION INFO
Hi Expert, My understanding is this please correct if I am wrong, Step 1) UE sent REGISTER with CSequence Number: 1804289384 and Call-ID: 28335007c4047a42 Step 2) 401 with CSequence Number: 1804289384 and Call-ID: 28335007c4047a42 Step 3) After challenge UE sent the REGISTER with CSequence Number: 1804289385 and Call-ID: 28335007c4047a42 Step 4 ) 200OK with same CSequence Number: 1804289385 and Call-ID: 28335007c4047a42which is expected . Call Continue... Everything is OK Step 5) UE sent DE-REGISTRATION with CSequence Number: 1804289386 and Call-ID: 28335007c4047a42 Step 6) 200OK for DE-REGISTRATION with same with CSequence Number: 1804289386 and Call-ID: 28335007c4047a42 which is also expected . Here all contacts are removed (all AOR binding clear) Step 7) UE now sent another fresh REGISTER request with CSequence Number: 1804289384 and Call-ID: ee74e9624ebe1844 Step 8) UAS is now rejecting continuously the REGISTER. So the question is in Step 7 ) the call id now changed to Call-ID: ee74e9624ebe1844 and as per RFC 3261 it says , 10.3 <https://tools.ietf.org/html/rfc3261#section-10.3> Processing REGISTER Requests Point 7. For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the binding does not exist, it is tentatively added. *If the* * binding does exist, the registrar checks the Call-ID value. If* * the Call-ID value in the existing binding differs from the* * Call-ID value in the request, the binding MUST be removed if* * the expiration time is zero and updated otherwise.* If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails. In our case the Call-ID: ee74e9624ebe1844 value us differ from the previous one so the UAS should update the binding and accept the REGISTER request instead rejecting it with 401. *Best Regards* *Rakesh Kumar Mohanty* On Fri, Jan 6, 2017 at 4:44 PM, Mohit Soni wrote: > Hi Rakesh, > > Full trace of your scenario or at least the message body of the fresh > REGISTER message sent from UE with new Call-ID may help figure out things. > > > Regards, > Mohit Soni > > On Fri, Jan 6, 2017 at 4:02 PM, Rakesh wrote: > >> Hi Expert, >> >> I need one info for the following below SIP REGISTER scenario. >> >> Step 1) UE sent REGISTER with CSeq =1 CallID=11 >> Step 2) 401 with CSeq =1 CallID=11 >> Step 3) After challenge UE sent the REGISTER with CSeq =2 CallID=11 >> Step 4 ) 200OK with same CSeq =2 CallID=11 which is expected . >> >> Call Continue... Everything is OK >> >> Step 5) UE sent DE-REGISTRATION with CSeq =3 CallID=11 >> Step 6) 200OK for DE-REGISTRATION with same CSeq =3 CallID=11 which >> is >> expected . Here all contacts are removed (all AOR binding clear) >> >> Step 7) UE now sent another fresh REGISTER request with CSeq =1 >> CallID=12 >> >> Step 8) UAS is now rejecting continuously the REGISTER. >> >> So the question is in Step 7 ) the call id now changed to 12 and as >> per >> RFC 3261 it says >> >> The first question is, >> >> It says 8.1.1.4 Call-ID >> >> >>The Call-ID header field acts as a unique identifier to group together >> a series of messages. It MUST be the same for all requests >>and responses sent by either UA in a dialogue. >> *It SHOULD be the same in each registration from a UA.* >> >> *Best Regards* >> >> *Rakesh Kumar Mohanty* >> ___ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SIP REGISTRTION INFO
Hi Expert, I need one info for the following below SIP REGISTER scenario. Step 1) UE sent REGISTER with CSeq =1 CallID=11 Step 2) 401 with CSeq =1 CallID=11 Step 3) After challenge UE sent the REGISTER with CSeq =2 CallID=11 Step 4 ) 200OK with same CSeq =2 CallID=11 which is expected . Call Continue... Everything is OK Step 5) UE sent DE-REGISTRATION with CSeq =3 CallID=11 Step 6) 200OK for DE-REGISTRATION with same CSeq =3 CallID=11 which is expected . Here all contacts are removed (all AOR binding clear) Step 7) UE now sent another fresh REGISTER request with CSeq =1 CallID=12 Step 8) UAS is now rejecting continuously the REGISTER. So the question is in Step 7 ) the call id now changed to 12 and as per RFC 3261 it says The first question is, It says 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialogue. *It SHOULD be the same in each registration from a UA.* *Best Regards* *Rakesh Kumar Mohanty* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] User Agent Info
Hi Expert, Is there any way to hide the User Agent header in SIP ? User-Agent: *Best Regards* *Rakesh Kumar Mohanty* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Media and Signaling IP
Hi Expert, Could you kindly please let me know is there any standard which says that the media and signaling IP should be diffrent in SIP INVITE .. This is the scenario , Packet 1 from UE -INVITE---PCSCF Packet 6 from UE -INVITE---PCSCF Time difference between both the INVITE is only 1 min . From UE “User-Agent: eyeBeam release 1003s stamp 31159” one of the Packet 1 (INVITE) both the Signaling and media IP is present on SDP , Internet Protocol Version 4, Src: 10.49.208.239 --- Signalling IP In SDP Connection Address: 10.49.208.039 --- Media IP . But if we check the later packate 6 (INVITE) from the same UE only signaling IP is coming on SDP and Media IP is not expose here , Internet Protocol Version 4, Src: *10.49.208.239* --- Signalling IP In SDP Connection Address: *10.49.208.239*--- Media IP So what is the RFC standard says here ? It should be same or ? I am asking because in both the case the core node accept and process the request .. So where is the behaviour of UE not ok or the behaviour of core node also not ok ? Another question is why the core node entertain this behavior of UE .. It should reject or its the correct behavior of core node ? *Best Regards* *Rakesh Kumar Mohanty* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Query on M line in SDP
Hi Team, I am getting in ACR (Accounting Charinging Request )that , The SDP-Media-Name has the following string: "m=image 0 udptl t38 ? m=image 0 udptl t38 ?m=audio 11348 RTP/AVP 8 0" The MM only validates nule strings, with 1 or 2 fields, never with 3. Is there any issue in the SDP part .? *Best Regards* *Rakesh Kumar Mohanty* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Regarding Registration on Brekeke server
Hi All, I have installed Brekeke Server ( Version 3.3.5.8 Evaluation) on Windows XP PC. The server is not responding to the registration messages sent form the User agent. Please do let me know if any additional settings are required for the same. Thanks, Rakesh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] DNS issue
The issue is that in the correct DNS server ,a new IP address is learnt for a FQDN. The IP address for the FQDN is never updated. This works the first couple of tmes and then fails . In the DNS query that fails , query has only _sip._udp and no DNS name and get a not found response. Thanks, Rakesh On Thu, Mar 21, 2013 at 10:23 AM, Kurtis vel wrote: > Do you mean a new IP was assigned to the user agent via DNS? If that is > the case are you registering the IP in the correct domain as a new sip > alias? > On Mar 20, 2013 11:33 AM, "Rakesh Rajkumar" > wrote: > >> Hi, >> >> Please let me know your inputs on the below issue. >> >> The User agent has got a new IP address from the DNS server. But it is >> not >> sending the requests to the new IP received. Is the issue related to >> RADV code or VXworks or application code . Any particular part that I >> need to focus on. >> >> Thanks, >> Rakesh >> ___ >> 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
[Sip-implementors] DNS issue
Hi, Please let me know your inputs on the below issue. The User agent has got a new IP address from the DNS server. But it is not sending the requests to the new IP received. Is the issue related to RADV code or VXworks or application code . Any particular part that I need to focus on. Thanks, Rakesh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Inputs required on Memory leak in RADV code
Hi, SIP stack version is 4.0.0.30. Thanks, Rakesh On Tue, Sep 11, 2012 at 8:11 PM, Ozdogru, Kutay wrote: > Hi Rakesh, > > Which version of RV SIP Stack are you using ? > > Kutay > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto: > sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Rakesh > Rajkumar > Sent: 10 September 2012 15:57 > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Inputs required on Memory leak in RADV code > > > > > Hi All, > > > > Observed memory leak (of about 32-48 bytes) for every incoming > > VoIP call . > > This occurs only when the session refresher is set to "UAC". Memory leak > is not seen when the session refresher is set to "UAS". > > Issue seems to be present in the Radvision code. > > Please let me know your inputs on the above issue. > > > > Thanks in advance. > > > > Regards, > > Rakesh > >India > ___ > 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
[Sip-implementors] Inputs required on Memory leak in RADV code
> > Hi All, > > Observed memory leak (of about 32-48 bytes) for every incoming > VoIP call . This occurs only when the session refresher is set to "UAC". Memory leak is not seen when the session refresher is set to "UAS". Issue seems to be present in the Radvision code. Please let me know your inputs on the above issue. > Thanks in advance. > > Regards, Rakesh India ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
