[Sip-implementors] To_Tag for INVITE client transaction is in the Calling state
Hi, when an INVITE client transaction is in the Calling state and proceeding state, on receipt of Success (200 OK) responses. Is ACK should send same as received To_Tag of To_Tag on ACK(sent)? Any help is appericated. Thanks Sudhir Save all your chat conversations. Find them online at http://in.messenger.yahoo.com/webmessengerpromo.php ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] ACKing 200 OKs
Once a transaction has been destroyed, shouldn't the UAS respond to the ACK with a 481? Or should it just silently absorb the ACK? Never send a response to an ACK request. The ACK request is a special request that has no response. ACK should always be silently absorbed. Regards, Attila -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Corbe Sent: 19 December 2007 18:39 To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] ACKing 200 OKs I'm having a bit of a hard time interpreting parts of the RFC relevant to sending an ACK in response to a 200 OK. Language like: Once the transaction is in the Terminated state, it MUST be destroyed immediately. As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE. and If, while in the Proceeding state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the Terminated state. Make me believe it's not possible for a UAC to send an ACK to a UAS in response to a 200 OK Once a transaction has been destroyed, shouldn't the UAS respond to the ACK with a 481? Or should it just silently absorb the ACK? -Daniel ___ 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] SDP longer than that given in Content-Lenght header
Hi, What should be the behavior when SDP is longer than that given in Content-Length header? The RFC 3261 section 18.3 Framing states: If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. So this means, SIP parser should discard the data beyond the length given by Content-Lenght header. In the below case the call should fail as we wont get enough data from SDP to complete the call as we will drop them. INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0 From: sipp sip:[EMAIL PROTECTED]:5061;tag=15126SIPpTag001 To: sut sip:[EMAIL PROTECTED]:5060 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5061 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp *Content-Length: 20* v=0 o=user1 53655765 2353687637 IN IP4 10.253.6.209 s=- c=IN IP4 10.253.6.209 t=0 0 m=audio 6001 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Please suggest what must be the behavior in this case. Thanks, Aneesh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP longer than that given in Content-Lenghtheader
Discard the extra bytes. You have no choice. And tell the UA vendor to fix their implementation. Regards, Attila -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aneesh Naik Sent: 20 December 2007 12:03 To: Sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SDP longer than that given in Content-Lenghtheader Hi, What should be the behavior when SDP is longer than that given in Content-Length header? The RFC 3261 section 18.3 Framing states: If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. So this means, SIP parser should discard the data beyond the length given by Content-Lenght header. In the below case the call should fail as we wont get enough data from SDP to complete the call as we will drop them. INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0 From: sipp sip:[EMAIL PROTECTED]:5061;tag=15126SIPpTag001 To: sut sip:[EMAIL PROTECTED]:5060 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5061 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp *Content-Length: 20* v=0 o=user1 53655765 2353687637 IN IP4 10.253.6.209 s=- c=IN IP4 10.253.6.209 t=0 0 m=audio 6001 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Please suggest what must be the behavior in this case. Thanks, Aneesh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP longer than that given in Content-Lenghtheader
Comments Inline... Regards, Nataraju A B -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aneesh Naik Sent: Thursday, December 20, 2007 5:33 PM To: Sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SDP longer than that given in Content-Lenghtheader Hi, What should be the behavior when SDP is longer than that given in Content-Length header? The RFC 3261 section 18.3 Framing states: If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. So this means, SIP parser should discard the data beyond the length given by Content-Lenght header. In the below case the call should fail as we wont get enough data from SDP to complete the call as we will drop them. INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0 From: sipp sip:[EMAIL PROTECTED]:5061;tag=15126SIPpTag001 To: sut sip:[EMAIL PROTECTED]:5060 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5061 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp *Content-Length: 20* v=0 o=user1 53655765 2353687637 IN IP4 10.253.6.209 s=- c=IN IP4 10.253.6.209 t=0 0 m=audio 6001 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Please suggest what must be the behavior in this case. [ABN] since this message is received over UDP transport, it would be preferred to consider whole packet and give less precedence to content-length header value. Even RFC.3261 suggests discard the rest of the bytes, but being liberal here would make the UA implementation more robust also. In case of TCP transport you should use the content-length header value strictly to determine the body of the received SIP request/response. This is my understanding, please add on if something better or preferred alternatives are available Thanks, Aneesh ___ Sip-implementors mailing list Sip-implementors@lists.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@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is it acceptable to have methods= param in theContact header for a REGISTER message
Do the spaces matter for SIP messages or their contents? According to 3840, the definitions for the methods= Feature Tag are in compliance with RFC2730, which specifies both textual and non-textual (ASN.1 encoded) representations for negotiating capabilities. I would be surprised if a SIP implementation - which is text based almost by definition - specified ASN.1 encoding for its message contents. Then again, what do I know? I certainly haven't read the entire RFC. :-) Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. -Original Message- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 7:31 PM To: Jeff Wright Cc: Amit P. Ahuja; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Is it acceptable to have methods= param in theContact header for a REGISTER message Right. I would however mention that the spaces within the quoted string value are incorrect. So it should be: Contact: sip:[EMAIL PROTECTED]:5060;methods=INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MES SAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER Paul Jeff Wright wrote: Hello, I just stumbled across this myself in the following RFC: http://tools.ietf.org/html/rfc3840 See in particular Section 6, Expressing Capabilities in a Registration. Best regards, Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. (303) 415 6149 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amit P. Ahuja Sent: Wednesday, December 19, 2007 4:05 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Is it acceptable to have methods= param in theContact header for a REGISTER message One of the SIP hardphones that I use sends out a REGISTER message with the Contact header that looks like: Contact: sip:[EMAIL PROTECTED]:5060;methods=INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER I could not find whether the methods= param in the Contact is acceptable as per RFC3261. I thought Allow: is the only way of specifying supported methods. Would someone know if it is valid and which RFC specifies so? Thanks and Regards, Amit Ahuja ___ 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 mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP reject in 200 OK
From: Harsha. R [EMAIL PROTECTED] If a UAC makes an SDP offer in RE-INVITE, can the offer be rejected in a 200 OK? No, of necessity, the SDP in a 200 OK is an SDP answer (if the INVITE contained an offer), and that SDP takes effect in the dialog. *However*, the SDP might include a decline of every media stream in the offered SDP. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is it acceptable to have methods= param in the Contact header for a REGISTER message
[EMAIL PROTECTED] wrote: Searching for methods in RFC 3840 turns up an oddity: Section 5 says: When using the sip.methods feature tag, a UA MUST NOT include values that correspond to methods not standardized in IETF standards track RFCs. but two paragraphs later it says: Furthermore, when a UA registers values for a particular feature tag, it MUST list all values that it supports. For example, when including the sip.methods feature tag, a UA MUST list all methods it supports. What should a UA do when it supports a non-standard method? Interesting discovery. I guess it had better not support any nonstandard values. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP reject in 200 OK
Interesting. I though the answer to that question was YES. But, I can understand Dale's response. So, you can accept an SDP offer (by sending back a 200 instead of a 488), while you may reject every media stream in the offer (by setting each m= line port equals to 0 in the answer). I'd have treated that as rejection, but since the SIP response code is 200 that's beeing deemed as acceptance. I guess, its just semantics :) -- Raj On Dec 20, 2007 2:59 PM, [EMAIL PROTECTED] wrote: From: Harsha. R [EMAIL PROTECTED] If a UAC makes an SDP offer in RE-INVITE, can the offer be rejected in a 200 OK? No, of necessity, the SDP in a 200 OK is an SDP answer (if the INVITE contained an offer), and that SDP takes effect in the dialog. *However*, the SDP might include a decline of every media stream in the offered SDP. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] 200 OK in calling state for INVITE client transaction
Hi All, when an INVITE client transaction is in the Calling state, on receipt of Success (200 OK) response. As per RFC 17.1.1.2(Figure 5: INVITE client transaction), the 2xx response MUST cause the client transaction to enter the Terminated state. But, I'm not sure what would be To_Tag in generating ACK for that 200 OK. Any response is highly appericated. Thanks, Sudhir Get the freedom to save as many mails as you wish. To know how, go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
