RE: [Sip-implementors] query regarding sip parser
Hi Naresh, Tcl/Tk does not take such a long time for parsing. I have worked and used on a SIP client which was completely written in Tcl/Tk and that worked just as efficiently as any other soft SIP clients I have seen. Regards, Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kotha naresh kumar Sent: Wednesday, August 24, 2005 2:56 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] query regarding sip parser hi i am writing a sip Parser in TCL i am able to write it but one problem i am facing is it is taking 15 minutes to interpert the SIP message can any one help me and suggest me any changes that i have do to i am even attaching my code please verify it and help me and one more question normally TCl will take this much amount of time in Parsing sip message ? does any one implemented SIP parser in TCL? please help me waiting for reply regards naresh Rock.com E-mail Now Has a HUGE 50MB of Storage! Sign Up Now! ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] XML parsing.
That will not be a problem. All you have to do is to extract the XML body from the SIP message and use an XML parser to parse it. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kishore Sowdi Sent: Wednesday, November 09, 2005 11:07 AM To: sip Subject: [Sip-implementors] XML parsing. Hi , I just want to know are there any XML parsers formatters available which could parse format XML name spaces in the SIP message (ex:NOTIFY). Or should i go for writing a linear parser myself. This XML stuff will not be a part of any SIP header but insted it will be a part of Content.Thats the problem i suppose. regards, KISHORE SOWDI. ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] To-Tag in INVITE request
Sigrid, Both are legally possible. The final result will depend on what you actually want. Please refer to sections 13.3.1 (point 3) and 12.2.2 in RFC 3261. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sigrid Thijs Sent: Friday, November 18, 2005 5:07 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] To-Tag in INVITE request Hi, when a UA receives an INVITE request with a to-tag it should check if there's a dialog that matches the request. But what if there's no matching dialog? Should the UA treat it as an in-dialog request and respond with an 481 (call leg/transaction does not exist) response. Or should the UA treat it as an out-of-dialog request, create a dialog and respond with 1xx reponses? Kind regards, Sigrid Thijs ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] CANCEL message construction at proxy level
Tadkot, I think the problem is here -- and insert it own VIA header field value. Section 9.1 of RFC 3261 states that - A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. I am not sure about the branch parameter though (but my guess is that should be the same too). Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, November 18, 2005 5:26 PM To: Sip-Implementors Subject: [Sip-implementors] CANCEL message construction at proxy level Hi All, I am new to this mail grpu and SIP world :). I need some information about how to construct the CANCEL message at the proxy level. Scenario 1 Caller A sends INVITE message to PROXY 2 PROXY(stateful) send 100 trying to caller A and sends the INVITE message to caller B 3 Caller A sends CANCEL message to PROXY to cancel the INVITE message 4 PROXY send 200 OK and 487 response back to Caller A and checks for 1xx response from caller B and construct the CANCEL message to send to caller B 5 PROXY construct this message with same Request-URI, TO , FROM, CALL-ID and Cseq number field values of the INVITE message send to caller B and insert it own VIA header field value. the branch id is different from the one which is sent in INVITE message to caller B. 5 But the CALLER B sends 481 Call/Transaction Does Not Exist message back to PROXY. NOTE: if the CALLER B is CISCO media gateway, then it accept CANCEL message by sending 200 OK and 487 message, But if it is a Pingtel phone then it sends 481. Any clue why the behavior is different here. Thanks and Regards -venkat ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Acknowledge for ACK?
If B doesn't receive A's ACK, B will retransmit the 200 OK. From that A will know whether B has received A's ACK or not. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of rahul Sent: Friday, December 09, 2005 7:19 PM To: Sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Acknowledge for ACK? Hi Everybody, I would like to know.. why there is no acknowledge for ACK sent by A to B. How will A know whether B has acknowledged A's ACK. A -Invite- B A--RingingB A---OK-- B A-ACK--- B Thanks in Advace, Ravichandra - Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] CANCEL request in the INVITE initiated Dialog
I guess section 9.1 in 3261 answers your question - The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Banibrata Dutta Sent: Thursday, December 15, 2005 3:02 PM To: Sip-Implementors (E-mail) Subject: [Sip-implementors] CANCEL request in the INVITE initiated Dialog hi, a CANCEL sent for an INVITE will in the INVITE initiated Dialog. So should the CANCEL request have both the From To tags, or just the From tag ? I believe that both should be sent, because the full Dialog related information could be available from the received provisional response (s.a. 182 or 183). thanks for any clarification. regards, bdutta ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] SIP/2.0 404 Not Found
Hi all, I am facing a strange problem with a UA I have been working on. While making an outgoing call the SIP proxy sends me a SIP/2.0 404 Not Found response with this UA. With X-Lite UA the call goes through. I have the INVITE message here for both calls - My UA - INVITE sip:[EMAIL PROTECTED] SIP/2.0 To: sip:[EMAIL PROTECTED] From: Staka sip:[EMAIL PROTECTED];tag=204320gsl Call-ID: 212570hfi CSeq: 3 INVITE Via: SIP/2.0/UDP 172.25.21.67:5060;branch=z9hG4bK822406dh;rport Allow: ACK,BYE,CANCEL,INVITE,INFO,NOTIFY,OPTIONS,PRACK,REFER,UPDATE Contact: sip:[EMAIL PROTECTED] Supported: 100rel,replaces,precondition Accept: application/sdp,application/cpim-pidf+xml Expires: 20 User-Agent: Conexant-User-Agent Route: sip:216.115.25.198:5061;lr Accept-Language: en Content-Type: application/sdp Content-Length: 189 Content-Language: en Content-Disposition: session Max-Forwards: 70 Proxy-Authorization: Digest username=19092661831,realm=216.115.25.198,nonce=1615157518,uri=si p:[EMAIL PROTECTED],response=76b9a0c9fd03109839cde4d10ef1f702 ,algorithm=MD5 v=0 o=19092661831 80 80 IN IP4 172.25.21.67 s=- c=IN IP4 172.25.21.67 t=0 0 m=audio 5000 RTP/AVP 0 8 18 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=sendrecv X-Lite: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 172.25.21.59:5061;rport;branch=z9hG4bK053619E2643044A9AD67BEA219B15568 From: 19092661831 sip:[EMAIL PROTECTED]:5061;tag=592405187 To: sip:[EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED]:5061 Call-ID: [EMAIL PROTECTED] CSeq: 60658 INVITE Proxy-Authorization: Digest username=19092661831,realm=216.115.25.198,nonce=1892854933,respons e=6fa38c4575158845baba85a32a4be548,uri=sip:[EMAIL PROTECTED] ,algorithm=MD5 Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1103m Content-Length: 199 v=0 o=19092661831 5428812 5428828 IN IP4 172.25.21.59 s=X-Lite c=IN IP4 172.25.21.59 t=0 0 m=audio 2 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 One difference between the 2 is that my UA has a route header. I removed the route header and tried with same results. I am registering with Vonage for these calls. Any clues what's wrong here? Any help would be appreciated. Thanks. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP/2.0 404 Not Found
Hi Shardul, I am not sure I understand you here. My UA offers codecs 0, 8, 18. X-Lite offers 0 and 101, and 0 are selected for RTP. Another thing, I don't think proxy would look at the SDP information. If the proxy is forwarding the called UA's response, what would a 404 response from a UAC mean? Thanks. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 2:39 PM To: Anshuman Rawat; sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] SIP/2.0 404 Not Found Hi Anshuman this is an Issue of Codec Change the Codec type of your UA. Regards, Shardul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anshuman Rawat Sent: Wednesday, December 21, 2005 2:30 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] SIP/2.0 404 Not Found Hi all, I am facing a strange problem with a UA I have been working on. While making an outgoing call the SIP proxy sends me a SIP/2.0 404 Not Found response with this UA. With X-Lite UA the call goes through. I have the INVITE message here for both calls - My UA - INVITE sip:[EMAIL PROTECTED] SIP/2.0 To: sip:[EMAIL PROTECTED] From: Staka sip:[EMAIL PROTECTED];tag=204320gsl Call-ID: 212570hfi CSeq: 3 INVITE Via: SIP/2.0/UDP 172.25.21.67:5060;branch=z9hG4bK822406dh;rport Allow: ACK,BYE,CANCEL,INVITE,INFO,NOTIFY,OPTIONS,PRACK,REFER,UPDATE Contact: sip:[EMAIL PROTECTED] Supported: 100rel,replaces,precondition Accept: application/sdp,application/cpim-pidf+xml Expires: 20 User-Agent: Conexant-User-Agent Route: sip:216.115.25.198:5061;lr Accept-Language: en Content-Type: application/sdp Content-Length: 189 Content-Language: en Content-Disposition: session Max-Forwards: 70 Proxy-Authorization: Digest username=19092661831,realm=216.115.25.198,nonce=1615157518,uri=si p:[EMAIL PROTECTED],response=76b9a0c9fd03109839cde4d10ef1f702 ,algorithm=MD5 v=0 o=19092661831 80 80 IN IP4 172.25.21.67 s=- c=IN IP4 172.25.21.67 t=0 0 m=audio 5000 RTP/AVP 0 8 18 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=sendrecv X-Lite: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 172.25.21.59:5061;rport;branch=z9hG4bK053619E2643044A9AD67BEA219B15568 From: 19092661831 sip:[EMAIL PROTECTED]:5061;tag=592405187 To: sip:[EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED]:5061 Call-ID: [EMAIL PROTECTED] CSeq: 60658 INVITE Proxy-Authorization: Digest username=19092661831,realm=216.115.25.198,nonce=1892854933,respons e=6fa38c4575158845baba85a32a4be548,uri=sip:[EMAIL PROTECTED] ,algorithm=MD5 Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1103m Content-Length: 199 v=0 o=19092661831 5428812 5428828 IN IP4 172.25.21.59 s=X-Lite c=IN IP4 172.25.21.59 t=0 0 m=audio 2 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 One difference between the 2 is that my UA has a route header. I removed the route header and tried with same results. I am registering with Vonage for these calls. Any clues what's wrong here? Any help would be appreciated. Thanks. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP/2.0 404 Not Found
Thanks all for your suggestions. The actual problem was that I had loose routing enabled while the proxy did not support loose routing. Disabling loose routing at my end solved the problem. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 4:09 PM To: Anshuman Rawat; [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] SIP/2.0 404 Not Found Anshuman, I believe the difference in behavior comes from the difference in the INVITE messages you present: Your UA: From: Staka sip:[EMAIL PROTECTED];tag=204320gsl To: sip:[EMAIL PROTECTED] X-Lite: From: 19092661831 sip:[EMAIL PROTECTED]:5061;tag=592405187 To: sip:[EMAIL PROTECTED] - You are running X-Lite on port 5061, and your own UAC on port 5060 - X-Lite puts this port in the From header (which it really shouldn't) - X-Lite is using a Call-ID including an '@' (this should really not matter though) - The displayname you use for X-Lite matches the username (really should not matter either, but...) The 404 is likely coming from the proxy, not the callee UA, and has nothing to do with the SDP Regards, Jeroen - Original Message - From: Anshuman Rawat [EMAIL PROTECTED] To: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu Sent: Wednesday, December 21, 2005 10:16 AM Subject: Re: [Sip-implementors] SIP/2.0 404 Not Found Hi Shardul, I am not sure I understand you here. My UA offers codecs 0, 8, 18. X-Lite offers 0 and 101, and 0 are selected for RTP. Another thing, I don't think proxy would look at the SDP information. If the proxy is forwarding the called UA's response, what would a 404 response from a UAC mean? Thanks. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 2:39 PM To: Anshuman Rawat; sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] SIP/2.0 404 Not Found Hi Anshuman this is an Issue of Codec Change the Codec type of your UA. Regards, Shardul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anshuman Rawat Sent: Wednesday, December 21, 2005 2:30 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] SIP/2.0 404 Not Found Hi all, I am facing a strange problem with a UA I have been working on. While making an outgoing call the SIP proxy sends me a SIP/2.0 404 Not Found response with this UA. With X-Lite UA the call goes through. I have the INVITE message here for both calls - My UA - INVITE sip:[EMAIL PROTECTED] SIP/2.0 To: sip:[EMAIL PROTECTED] From: Staka sip:[EMAIL PROTECTED];tag=204320gsl Call-ID: 212570hfi CSeq: 3 INVITE Via: SIP/2.0/UDP 172.25.21.67:5060;branch=z9hG4bK822406dh;rport Allow: ACK,BYE,CANCEL,INVITE,INFO,NOTIFY,OPTIONS,PRACK,REFER,UPDATE Contact: sip:[EMAIL PROTECTED] Supported: 100rel,replaces,precondition Accept: application/sdp,application/cpim-pidf+xml Expires: 20 User-Agent: Conexant-User-Agent Route: sip:216.115.25.198:5061;lr Accept-Language: en Content-Type: application/sdp Content-Length: 189 Content-Language: en Content-Disposition: session Max-Forwards: 70 Proxy-Authorization: Digest username=19092661831,realm=216.115.25.198,nonce=1615157518,uri=si p:[EMAIL PROTECTED],response=76b9a0c9fd03109839cde4d10ef1f702 ,algorithm=MD5 v=0 o=19092661831 80 80 IN IP4 172.25.21.67 s=- c=IN IP4 172.25.21.67 t=0 0 m=audio 5000 RTP/AVP 0 8 18 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=sendrecv X-Lite: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 172.25.21.59:5061;rport;branch=z9hG4bK053619E2643044A9AD67BEA219B15568 From: 19092661831 sip:[EMAIL PROTECTED]:5061;tag=592405187 To: sip:[EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED]:5061 Call-ID: [EMAIL PROTECTED] CSeq: 60658 INVITE Proxy-Authorization: Digest username=19092661831,realm=216.115.25.198,nonce=1892854933,respons e=6fa38c4575158845baba85a32a4be548,uri=sip:[EMAIL PROTECTED] ,algorithm=MD5 Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1103m Content-Length: 199 v=0 o=19092661831 5428812 5428828 IN IP4 172.25.21.59 s=X-Lite c=IN IP4 172.25.21.59 t=0 0 m=audio 2 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 One difference between the 2 is that my UA has a route header. I removed the route header and tried with same results. I am registering with Vonage for these calls. Any clues what's wrong here? Any help would be appreciated. Thanks. Regards, Anshuman S. Rawat Software Group, Conexant Systems India Private Ltd. ** Legal Disclaimer
Re: [Sip-implementors] Multiple 2xx responses
See inline. Regards, Anshuman 2. Though an ACK is sent back to all, which one should be considered finally ? - their will be only one ACK response from UAC that will the server transaction to transition itself from completed to confirmed state, rest of all ACK's will be absorbed by UAS having no effect of server transaction state. [ASR] I think the above explanation might be incorrect. Section 13.1 in 3261 states that - A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call. This explanation should also answer the original question. 3.Can all of them contain SDPs (pbly answer SDPs)? - each of the 200Ok response can or need not have the SDP, if one retransmission has SDP answer than all will have. Remember answer can also be sent in 1xx provisional response like 180 ringing. [ASR] I think that it still has to send SDP in 200 OK even if the answer has been sent by a provisional response. Can some 3rd person confirm? Regards, Priya. ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple non- 2xx responses
Here's the answer from Section 13.2.2.3 of 3261 - A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored. HTH, Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Pandaram Sent: Friday, January 13, 2006 1:51 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Multiple non- 2xx responses Is it possible for a UAC to receive multiple non-2xx responses for an INVITE (because a call was forked and the forking proxy sent through both of them to a UAC)? What should be the UAC behavior in such a scenario? - Andy Send instant messages to your online friends http://in.messenger.yahoo.com ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] BYE in Cisco 7960 Pulver
This behavior is also noticed only for long duration calls (in my case about 10 minutes+). A slight correction - This behavior is only noticed for long duration calls (about 10 mins and more). Thanks, Anshuman -Original Message- From: Anshuman Rawat Sent: Monday, January 30, 2006 4:51 PM To: sip-implementors@cs.columbia.edu Subject: BYE in Cisco 7960 Pulver Hi, I have a Cisco 7960 IP phone registered with Pulver (fwd.pulver.com) and I noticed something strange with its behavior when it's registered with Pulver. Scenario is - There's a call between Cisco's IP phone and another IP phone. After about 10 minutes into the call, I hang-up at Cisco phone end resulting in a BYE request being sent out. But the request URI in the BYE request is of the Cisco phone itself and not of the other party (??). Result is Pulver sending a 408 response (request timed out). This behavior is also noticed only for long duration calls (in my case about 10 minutes+). I also have a short ethereal trace here. Any clue why this would happen? Thanks, Anshuman Regards, Anshuman S. Rawat ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Record-Route with same field values
Hi, I have 2 IP phones (1 Cisco 7960 another IP phone, say IP phone A) registered with fwd.pulver.com. When calling Cisco from IP phone A, I noticed that the INVITE which Cisco received that 2 equal Record-Route values. It probably is 'cause of the fact that the INVITE contained 2 VIA field values with same IP address but different branch parameters (see bolded text in 2nd INVITE below). I can't understand why the proxy (fwd.pulver.com) inserted 2 VIA header fields. Also, would there be any impact on routing if Record-Route has 2 identical field values? Any explanation for this behavior? Thanks in advance, Anshuman PS: 1. First INVITE message below is from IP phone A to proxy (fwd.pulver.com). Second INVITE is from proxy to Cisco. 2. When calling from Cisco to IP phone A, the proxy inserts only one VIA header, as I was expecting (INVITE message not pasted here). INVITE sip:[EMAIL PROTECTED] SIP/2.0 To: sip:[EMAIL PROTECTED] From: Staka sip:[EMAIL PROTECTED];tag=200340ghj Call-ID: 210950h9! CSeq: 3 INVITE Via: SIP/2.0/UDP 172.25.21.217:5060;branch=z9hG4bK283970mxu;rport Allow: ACK,BYE,CANCEL,INVITE,INFO,NOTIFY,OPTIONS,PRACK,REFER,UPDATE Contact: sip:[EMAIL PROTECTED] Supported: 100rel,replaces,precondition Accept: application/sdp,application/cpim-pidf+xml Expires: 3600 User-Agent: Conexant-User-Agent Route: sip:fwd.pulver.com:5060;lr Accept-Language: en Content-Type: application/sdp Content-Length: 196 Content-Language: en Content-Disposition: session Max-Forwards: 70 v=0 o=731346 550 550 IN IP4 172.25.21.217 s=SIP Phone c=IN IP4 172.25.21.217 t=0 0 m=audio 5000 RTP/AVP 0 8 18 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=sendrecv INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Record-Route: sip:[EMAIL PROTECTED];ftag=200340ghj;lr=on Record-Route: sip:[EMAIL PROTECTED];ftag=200340ghj;lr=on To: sip:[EMAIL PROTECTED] From: Staka sip:[EMAIL PROTECTED];tag=200340ghj Call-ID: 210950h9! CSeq: 3 INVITE Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK0ceb.85584e86.0 Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK0ceb.75584e86.0 Via: SIP/2.0/UDP 172.25.21.217:5060;branch=z9hG4bK283970mxu;rport=30719 Allow: ACK,BYE,CANCEL,INVITE,INFO,NOTIFY,OPTIONS,PRACK,REFER,UPDATE Contact: sip:[EMAIL PROTECTED]:5060 Supported: 100rel,replaces,precondition Accept: application/sdp,application/cpim-pidf+xml Expires: 3600 User-Agent: Conexant-User-Agent Accept-Language: en Content-Type: application/sdp Content-Length: 196 Content-Language: en Content-Disposition: session Max-Forwards: 68 v=0 o=731346 550 550 IN IP4 172.25.21.217 s=SIP Phone c=IN IP4 172.25.21.217 t=0 0 m=audio 5000 RTP/AVP 0 8 18 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=sendrecv Regards, Anshuman S. Rawat ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Record-Route with same field values
Hi, This behavior is only noticed in 1 direction i.e. for calls from IP phone A to Cisco 7960. It never happens for calls from Cisco phone to IP phone A. I have the INVITEs pasted here. In the 2nd INVITE, we can see that there are 2 distinct VIA headers and only 1 Record-Route value. Thanks for responding, Anshuman - (INVITE from Cisco to Pulver) INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 172.25.21.209:5060;branch=z9hG4bK143877ae From: 731348 sip:[EMAIL PROTECTED];tag=001360b51e8c003d3165ba76-086d194f To: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] Date: Wed, 01 Feb 2006 05:26:29 GMT CSeq: 102 INVITE User-Agent: CSCO/7 Contact: sip:[EMAIL PROTECTED]:5060 Proxy-Authorization: Digest username=731348,realm=fwd.pulver.com,uri=sip:69.90.155.70,response =5129a2142571b85e96477225216b2f9b,nonce=43e04c627ed4dbfb9be2911b9d475 6bce2d23fb4,algorithm=md5 Expires: 180 Content-Type: application/sdp Content-Length: 248 v=0 o=Cisco-SIPUA 21088 7404 IN IP4 172.25.21.209 s=SIP Call c=IN IP4 172.25.21.209 t=0 0 m=audio 24168 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 - (INVITE from Pulver to IP phone A) INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Max-Forwards: 10 Record-Route: sip:[EMAIL PROTECTED];ftag=001360b51e8c003d3165ba76-086d194f;lr=on Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bKc2ec.c87c57a.0 Via: SIP/2.0/UDP 172.25.21.209:5060;branch=z9hG4bK143877ae From: 731348 sip:[EMAIL PROTECTED];tag=001360b51e8c003d3165ba76-086d194f 4To: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] Date: Wed, 01 Feb 2006 05:26:29 GMT CSeq: 102 INVITE User-Agent: CSCO/7 Contact: sip:[EMAIL PROTECTED]:5060 Proxy-Authorization: Digest username=731348,realm=fwd.pulver.com,uri=sip:69.90.155.70,response =5129a2142571b85e96477225216b2f9b,nonce=43e04c627ed4dbfb9be2911b9d475 6bce2d23fb4,algorithm=md5 Expires: 180 Content-Type: application/sdp Content-Length: 248 v=0 o=Cisco-SIPUA 21088 7404 IN IP4 172.25.21.209 s=SIP Call c=IN IP4 172.25.21.209 t=0 0 m=audio 24168 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 From: Manjunath Warad [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 01, 2006 2:35 PM To: Anshuman Rawat; sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] Record-Route with same field values Hi, After analysing the message, I guess the message is spiralled in the proxy. Since the 2 branch are different inserted by proxy, I came to such conclusion. Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK0ceb.85584e86.0 Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK0ceb.75584e86.0 Via: SIP/2.0/UDP 172.25.21.217:5060;branch=z9hG4bK283970mxu;rport=30719 Request might have traversed in this way, IP Phone A Proxy(fwd.pulver.com)Cisco7960 This proxy adds two RR and two Via. But I dont know for what reason the request spiralled in the proxy. Regards, Manju -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Anshuman Rawat Sent: Wednesday, February 01, 2006 11:16 AM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Record-Route with same field values Hi, I have 2 IP phones (1 Cisco 7960 another IP phone, say IP phone A) registered with fwd.pulver.com. When calling Cisco from IP phone A, I noticed that the INVITE which Cisco received that 2 equal Record-Route values. It probably is 'cause of the fact that the INVITE contained 2 VIA field values with same IP address but different branch parameters (see bolded text in 2nd INVITE below). I can't understand why the proxy (fwd.pulver.com) inserted 2 VIA header fields. Also, would there be any impact on routing if Record-Route has 2 identical field values? Any explanation for this behavior? Thanks in advance, Anshuman PS: 1. First INVITE message below is from IP phone A to proxy (fwd.pulver.com). Second INVITE is from proxy to Cisco. 2. When calling from Cisco to IP phone A, the proxy inserts only one VIA header, as I was expecting (INVITE message not pasted here). INVITE sip:[EMAIL PROTECTED] SIP/2.0 To: sip:[EMAIL PROTECTED] From: Staka sip:[EMAIL PROTECTED];tag=200340ghj Call-ID: 210950h9! CSeq: 3 INVITE Via: SIP/2.0/UDP 172.25.21.217:5060;branch=z9hG4bK283970mxu;rport Allow: ACK,BYE,CANCEL,INVITE,INFO,NOTIFY,OPTIONS,PRACK,REFER,UPDATE Contact: sip:[EMAIL PROTECTED] Supported: 100rel,replaces,precondition Accept: application/sdp,application/cpim-pidf+xml Expires: 3600 User-Agent: Conexant-User-Agent Route: sip:fwd.pulver.com:5060;lr Accept-Language: en Content-Type: application/sdp Content-Length: 196 Content-Language: en Content-Disposition
Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging
Will having a few less headers really have much affect in CPU time? Since it is a SIP message, UAS will have to do all the things necessary to process any SIP request. Another point, although a 200 OK response makes sense, but practically any response back to UAC would suggest that UAS is alive. Right? And in case the UAS is down, UAC will have to wait for a timeout to occur for it to know that UAS is down. This might take a while, coming back to original problem (which started this thread). Regards, Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darshan Bildikar Sent: Wednesday, February 22, 2006 2:18 PM To: 'OmPrakashTripathi 70630'; [EMAIL PROTECTED] Cc: sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging OM... As you know per RFC 3261 OPTIONS is meant for exchanging capabilities (i.e. an options would be processed and answered like an INVITE) and not for heartbeat. In that sense PING would be like a stripped down version which would take up lesser CPU time. There's a thread going on in the SIP working group about the same issue although that also talks about refresh of NAT bindings. Check it out at http://www1.ietf.org/mail-archive/web/sip/current/msg12806.html Darshan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OmPrakashTripathi 70630 Sent: Wednesday, February 22, 2006 12:38 PM To: [EMAIL PROTECTED] Cc: 'sip-implementors@cs.columbia.edu' Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging Hi Frank, In this draft, you are suggesting to use a new PING method for the Heart Beat kinda considerations between the two UAs. Can you please tell us, in what sense is it different (or say advantageous) than the OPTIONS method, already suggested byt 3261. Thanks, Om.. ** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! * - Original Message - From: Frank W. Miller [EMAIL PROTECTED] Date: Wednesday, February 22, 2006 10:56 am Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging There is a draft being discussed on the SIP list right now to implementa PING method. See http://www.cornfed.com/ping.txt or http://www.cornfed.com/ping.html for the most recent version. All comments are welcome since this is a very new draft. FM On Tue, 2006-02-21 at 11:07 -0500, Sweeney, Andrew (Andrew) wrote: Hi, I am looking for any draft of RFC that defines how to basically heartbeat a sip device to know if it is active. Basically in a fault tolerent enviroment I don't want to send a request to a non responsive device. Presumably I would have knowlege of a backup. I have implemented a version of sending periodic OPTIONS requests to my devices as a form of heartbeat but it could take up to the invite timeout to know if they are alive. That can be a long time. Is there any universal method for handling this? Is there any RFCs or Drafts for SIP in a fault tolerent enviroment? Thanks Andy ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list
Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging
Yes, I did check that thread (and the consensus seems to be in favor of STUN for TCP). Since PING method suggested here is also a SIP method, I don't quite understand what it can do that OPTIONS cant. Regards, Anshuman -Original Message- From: Darshan Bildikar [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 4:38 PM To: Anshuman Rawat; 'OmPrakashTripathi 70630'; [EMAIL PROTECTED] Cc: sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging Check out the original SIP thread. They are talking about using STUN for UDP (for keep alive and update of NAT bindings) which will be about a 10% processing time as compared to a SIP request. (This will mean one port will handle two protocols) It started out with the suggestion that double CRLF be used for TCP. Not sure what the consensus is yet. -Original Message- From: Anshuman Rawat [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 4:23 PM To: [EMAIL PROTECTED]; OmPrakashTripathi 70630; [EMAIL PROTECTED] Cc: sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging Will having a few less headers really have much affect in CPU time? Since it is a SIP message, UAS will have to do all the things necessary to process any SIP request. Another point, although a 200 OK response makes sense, but practically any response back to UAC would suggest that UAS is alive. Right? And in case the UAS is down, UAC will have to wait for a timeout to occur for it to know that UAS is down. This might take a while, coming back to original problem (which started this thread). Regards, Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darshan Bildikar Sent: Wednesday, February 22, 2006 2:18 PM To: 'OmPrakashTripathi 70630'; [EMAIL PROTECTED] Cc: sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging OM... As you know per RFC 3261 OPTIONS is meant for exchanging capabilities (i.e. an options would be processed and answered like an INVITE) and not for heartbeat. In that sense PING would be like a stripped down version which would take up lesser CPU time. There's a thread going on in the SIP working group about the same issue although that also talks about refresh of NAT bindings. Check it out at http://www1.ietf.org/mail-archive/web/sip/current/msg12806.html Darshan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OmPrakashTripathi 70630 Sent: Wednesday, February 22, 2006 12:38 PM To: [EMAIL PROTECTED] Cc: 'sip-implementors@cs.columbia.edu' Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging Hi Frank, In this draft, you are suggesting to use a new PING method for the Heart Beat kinda considerations between the two UAs. Can you please tell us, in what sense is it different (or say advantageous) than the OPTIONS method, already suggested byt 3261. Thanks, Om.. ** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! * - Original Message - From: Frank W. Miller [EMAIL PROTECTED] Date: Wednesday, February 22, 2006 10:56 am Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging There is a draft being discussed on the SIP list right now to implementa PING method. See http://www.cornfed.com/ping.txt or http://www.cornfed.com/ping.html for the most recent version. All comments are welcome since this is a very new draft. FM On Tue, 2006-02-21 at 11:07 -0500, Sweeney, Andrew (Andrew) wrote: Hi, I am looking for any draft of RFC that defines how to basically heartbeat a sip device to know if it is active. Basically in a fault tolerent enviroment I don't want to send a request to a non responsive device. Presumably I would have knowlege of a backup. I have implemented a version of sending periodic OPTIONS requests to my devices as a form of heartbeat but it could take up to the invite timeout to know if they are alive. That can be a long time. Is there any universal method for handling this? Is there any RFCs or Drafts for SIP in a fault tolerent enviroment? Thanks Andy ___ Sip
[Sip-implementors] Matching Requests to Server Transactions
Hi All, I have a question regarding matching server transactions. I tried to google for the problem but couldn't find the answer. Section 17.2.3 says The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. My question is - if the top VIA header does not have a 'sent-by' parameter, what happens to the transaction matching procedure? Is step 2 ignored in such a case? TIA, Anshuman ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query on Re-Invite
[inline] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ashish Kumar Sent: Thursday, May 04, 2006 3:00 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Query on Re-Invite Hi, I have question on following scenario. A ---(Invite)-- B A --(183) B A --(200) B A ---(ACK)-- B A --(Re-Invite)--- B A --- (Bye) --- B A -- (200 for Bye) B What should be the behavior after this. Should B stop retransmitting Re-Invite and then wait for Timer B to fire. Or should B clear call, dialog and transaction immediately on receiving 200 for Bye. If A received the INVITE (re-invite) after it sent the BYE request, it should respond with a 481 'Call-leg/transaction does not exist' final response. Else A has to wait for the re-invite procedure to end before sending BYE. Anshuman ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] How to recognize Merging Requests at transactionLayer ( 482 Response )
Nitin, Your question was answered by Dale when you posted it the first time. Quoting him - The above chart is incorrect -- when a proxy sends a request on, it adds it's Via *first*. Thus, the two sets of Via's shown are reversed from what they should be. And the two copies of the request have different topmost branch parameters, b and c. (interop.pingtel.com has a test for merged requests. We've discovered that almost all UAs do not handle merged requests correctly the first time they are tested.) e.g. when the request through Proxy A reaches the server the VIA header would be in the order - Via: proxy_A; branch=d Via: forking_proxy; branch=b Via: client; branch= a That solves the issue. Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nitin arora Sent: Monday, May 29, 2006 9:56 AM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] How to recognize Merging Requests at transactionLayer ( 482 Response ) Hi, Last time when i sent the same query diagram got currupted this time i believe it should not happen. I have a doubt about Merged Requests. Please go through the following section of RFC3261. === 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. Now consider the following scenario: Note: I am using a, b, c for branch ids just make it more readable. | | | Client| |___| | | Via: client; branch=a | V |forking| |proxy | |___| | | forking proxy forks it in two | || || || || || | Via: client; branch=a| Via: client; branch=a | Via: forking_proxy; branch= b| Via: forking_proxy; branch= c VV | || | |proxy_A||proxy_B| |___||___| || | Via: client; branch= a |Via: client; branch=a | Via: forking_proxy; branch= b|Via: forking_proxy; branch = c | Via: proxy_A; branch= d |Via: proxy_B; branch = e V| | | | | |Server |--- |___| Implementations complaint to RFC3261 (section 17.2.3) for matching transaction wont be able to distinguish between these requests and this request which follows the path of proxy B will hit exactly at the same transaction as request through A because top via headers are identical. (branch, sent-by-value and method all three will be same for both the requests) Transaction layer in this case will return the same response as it returned for the previous request coming from A. Transaction layer treats the second request as a retransmission whereas it is not a retransmission and a 482 response is expected to be returned for this request. One way to resolve the above mentioned issue is to compare the complete via list. Now if we compare the complete list then request coming from B will not match with any of the transactions and will reach UA. Now UA core complaint to RFC3261 (section 8.2.2.2) will know that this request did not match any of the transactions and it will attempt to search a transaction having the same CallId, From Tag and CSeq as this current request has. It will be able to do so as transaction for request A still exists, and hence it will be able to return 482 response. Now my doubt is that RFC3261 does not talk about comparing the complete via list then how could it write section 8.2.2.2 because this code leg is not going to hit in any scenario. (means never be executed). Because all merging requests will
Re: [Sip-implementors] 302 and sequential search
So what if, in a 302 response, you received a contact like this Contact:sip:[EMAIL PROTECTED]:5060;user=phone;q=0.5,sip:[EMAIL PROTECTED]: 5060;user=phone;q=0.25 So what should you do if the first contact (at 192.168.0.4) gives no response at all? I would assume that the transaction would time-out (equivalent to a 408 response) and then proceed on to the next attempt. -Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: Friday, June 16, 2006 3:31 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] 302 and sequential search Hello all, In RFC3261 it says: Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search. Note that only after the previous has generated a final response. So what if, in a 302 response, you received a contact like this Contact:sip:[EMAIL PROTECTED]:5060;user=phone;q=0.5,sip:[EMAIL PROTECTED]:5 060;user=phone;q=0.25 So what should you do if the first contact (at 192.168.0.4) gives no response at all? Regards, Attila Attila Sipos http://www.vegastream.com ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multimedia Ring
I think this might be what you are looking for - http://www.ietf.org/rfc/rfc3960.txt Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ??? Sent: Wednesday, June 21, 2006 11:40 AM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Multimedia Ring Dear all, Does anybody know about SIP multimedia ring (M-Ring) call flow? In case of using Multimedia Server (MMS), how can I let the callee UA ring a sound that was stored in MMS when it receives a normal INVITE? Where can I get any reference document for this? Thanks. Sean ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Handling out of sequence requests
I believe in such a case it might be a re-transmission of an earlier request. If it matches an existing transaction, it should re-transmit the response. If it doesn't, it could be a delayed re-transmitted request or a new one (assuming that UAC generating the new request erroneously doesn't increment the CSeq number). Either ways, I think it should be responded with a 500 response. But I am not sure about that. Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 12:19 PM To: sip-implementors@cs.columbia.edu Cc: [EMAIL PROTECTED] Subject: [Sip-implementors] Handling out of sequence requests Hi, According to section 12.2.2 of RFC 3261, If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. The RFC however does not specify the UAS behaviour in case a request is recieved which has a CSeq number that is EQUAL to the remote CSeq number (which could be possible due to network delays). What should be the ideal behaviour of the UAS in this case? Which failure response should be sent? Thanks rgds, Shweta. ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] UAS behavior when R-URI doesn't contain username
It's also possible that the device has an outbound proxy configured which follows strict routing. In such cases, the R-URI would be URI of the outbound proxy which wouldn't have the user part. -Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 8:07 PM To: sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] UAS behavior when R-URI doesn't contain username From: Leonid Fainshtein [EMAIL PROTECTED] Sometimes I see devices that send INVITE without user name in R-URI but in the To header field it appears. Must a VoIP gateway reject such request or instead take the user name from header To and initiate call to PSTN. For example: INVITE sip:1.2.3.4:5;transport=UDP SIP/2.0 From: sip:[EMAIL PROTECTED];tag=40de6bc8-c24334bd-13c4-26c596-6af63e5f-26c596 To: sip:[EMAIL PROTECTED] As you can see the UAC invites UAS to make call to telephone number 6555. A gateway (or other device) should not take any automated action based on the To URI, only on the Request-URI. That is because the INVITE may have passed through multiple proxies and various forwarding operations; the information about the real destination of the call should be entirely contained in the Request-URI. It is possible that the gateway is configured to know what to do with an INVITE with a Request-URI without a user-part, but most likely it should reject it as having an unusable address. Dale ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple Contacts and BYE
Now I have some people who believe that since there is no response, the UserAgent1 should then try BYE [EMAIL PROTECTED] What will that achieve? In all likelihood, device at IP 2.2.2.2 has no clue about the dialog between UA1 and device at IP 1.1.1.1. It makes no sense to send BYE request to [EMAIL PROTECTED] only to get a '487 Call leg does not exist' response (I think). Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: Friday, July 07, 2006 12:33 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Multiple Contacts and BYE I would like to ask a question about the following scenario... UserAgent1 INVITE--- --302 with Contact: sip:[EMAIL PROTECTED];sip:[EMAIL PROTECTED] ACK--- so it gets redirected... INVITE [EMAIL PROTECTED] -100/180/200--- ACK- Then later it hangs up... BYE [EMAIL PROTECTED] no response BYE [EMAIL PROTECTED] after a several retries, UserAgent1 eventually gives up Now I have some people who believe that since there is no response, the UserAgent1 should then try BYE [EMAIL PROTECTED] But I believe that they are wrong. Who is right? Regards, Attila Attila Sipos http:/www.vegastream.com ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple Contacts and BYE
The reason I think their idea is wrong is because I believe that once the INVITE gets a 200 response, the multiple contact information (sip:[EMAIL PROTECTED];sip:[EMAIL PROTECTED]) from the 302 is thrown away and only the Contact in the 200 response is actually valid now. Is this correct? The RFC (3261) doesn't state what happens to the target set after a successful response (200 OK) is received. But for the problem in question it seems irrelevant. BYE is sent to the contact address received in 200 OK for INVITE. And the protocol hasn't defined to have a target set for BYE requests (most likely cause of the first reason). -Anshuman -Original Message- From: Attila Sipos [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 1:38 PM To: Anshuman Rawat; sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] Multiple Contacts and BYE I think they have a sort of proxy redundancy idea where they use the Contact in the 302 to indicate a proxy at 1.1.1.1 and a proxy at 2.2.2.2. But I just don't think this is the right way to do it. The reason I think their idea is wrong is because I believe that once the INVITE gets a 200 response, the multiple contact information (sip:[EMAIL PROTECTED];sip:[EMAIL PROTECTED]) from the 302 is thrown away and only the Contact in the 200 response is actually valid now. Is this correct? Regards, Attila -Original Message- From: Anshuman Rawat [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 08:58 To: Attila Sipos; sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] Multiple Contacts and BYE Now I have some people who believe that since there is no response, the UserAgent1 should then try BYE [EMAIL PROTECTED] What will that achieve? In all likelihood, device at IP 2.2.2.2 has no clue about the dialog between UA1 and device at IP 1.1.1.1. It makes no sense to send BYE request to [EMAIL PROTECTED] only to get a '487 Call leg does not exist' response (I think). Anshuman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: Friday, July 07, 2006 12:33 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Multiple Contacts and BYE I would like to ask a question about the following scenario... UserAgent1 INVITE--- --302 with Contact: sip:[EMAIL PROTECTED];sip:[EMAIL PROTECTED] ACK--- so it gets redirected... INVITE [EMAIL PROTECTED] -100/180/200--- ACK- Then later it hangs up... BYE [EMAIL PROTECTED] no response BYE [EMAIL PROTECTED] after a several retries, UserAgent1 eventually gives up Now I have some people who believe that since there is no response, the UserAgent1 should then try BYE [EMAIL PROTECTED] But I believe that they are wrong. Who is right? Regards, Attila ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
