[Sip-implementors] Media performance test-tool requested
Hi all, Does anybody know a free test-tool to test the performance of e.g. a DSL-modem regarding the short packets used by G.729? I recently used iperf, but this tool produces bursts and does not simulate the steady stream of media packets very well. Regards Franz ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] UPDATE with ANSWER?
Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017. html http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017 .html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] RE: [Sip] UPDATE with ANSWER?
Hi No UPDATE cannot be used to send answer, since UPDATE can be used only after a dialog is established. Regards Ranjit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chauhan Bhavik-A20762 Sent: Thursday, May 19, 2005 3:10 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] UPDATE with ANSWER? Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017. html http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017 .html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] PTT Query
Hi I have a query regarding PTT If simultaneously 10 users press the button who will get the priority and on what basis OR NO ONE WILL GET PRIORITY VISHAL ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] RE: [Sip] UPDATE with ANSWER? (18x using TCP)
Hi, I just thought I'd try to clarify something: 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? In SIP, TCP is not considered to be any more reliable than UDP. In other words - whether you use TCP or UDP: 1. you have to do retransmissions of SIP messages for TCP (in the same way that you do for UDP) 2. As far as SIP is concerned, PRACK is the only reliable way to transport 18x messages (using TCP or UDP) Regards, Attila Attila Sipos http://www.vegastream.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Avasarala Ranjit-A20990 Sent: 19 May 2005 10:51 To: Chauhan Bhavik-A20762; sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip-implementors] RE: [Sip] UPDATE with ANSWER? Hi No UPDATE cannot be used to send answer, since UPDATE can be used only after a dialog is established. Regards Ranjit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chauhan Bhavik-A20762 Sent: Thursday, May 19, 2005 3:10 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] UPDATE with ANSWER? Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004- January/006017. html http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017 .html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] RE: [Sip] UPDATE with ANSWER?
Hi, If you don't use PRACK you can't send a valid offer in a 18x. An offer (and an answer) has to be sent reliably. Regards, Christer Holmberg LM Ericsson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chauhan Bhavik-A20762 Sent: 19. toukokuuta 2005 12:40 To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] UPDATE with ANSWER? Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017.html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] VIA HEADER -Sent-By
Hello all, RFC 3261 says Before a request is sent, the client transport MUST insert a value of the sent-by field with FQDN or IP and Port into the Via header field. I dont see an UAC inserting a sent-by in the VIA header.Normally a VIA header would look like this, INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob sip:[EMAIL PROTECTED] From: Alice sip:[EMAIL PROTECTED];tag=1928301774 The above VIA with Default port as 5060,transport as UDP and PC33.atlanta.com as FQDN is sufficient enough to send the response back to the client in case of any connection error or Transport error encountered at the server. Can any one explain the Significance of sent-by. Thanks in Advance Confidentiality Notice 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 confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] UPDATE with ANSWER?
We really need to create an FAQ about this. A long time ago, probably in the thread you cite, we debated this extensively. It is true that the RFCs are not entirely clear on this, and reasonable people can differ in interpretation of them. But we finally came to some agreement on it. I am quite sure we agreed that UPDATE could *not* be used to send an answer. We ended up with a quite restrictive list of cases for how INVITE, UPDATE, PRACK, and their responses and ACK can be used to convey offer/answer. I was one who originally argued for fewer restrictions. But there were issues with that, and the restrictive approach won out. In practice I don't think the restrictions impose any great burden. Paul Chauhan Bhavik-A20762 wrote: Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017. html http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017 .html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] help me about proxy and sip register resoluation
Hi, Actaully in my application there is no fecility to domain name mapping,i mean it is having an option for only IP it is not having fecility for DNS(i mean for interop.pingtel.com).that's why i'm unable to connect ur's online servers. please give me solution for this, Thanks and regards, Bharath Reddy M S/W Engineer, HELLOSOFT INDIA PRIVATE Ltd. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] Question about the Attended Transfer
From: Todd Huang TransferorTransferee Transfer || Target ||| dialog1 | INVITE/200 OK/ACK | |---|| dialog1 | INVITE (hold)/200 OK/ACK| |---| | dialog2 | INVITE/200 OK/ACK | |---| == dialog2 | INVITE (hold)/200 OK/ACK | |---| dialog3 | REFER (Refer-To:sips:TransferTarget?Replaces=dialog2) |---| | dialog3 | 202 Accepted | | |---| | Please see the messages headed by the == sign. Why the Transferor needs to hold the Transfer Target before sending REFER to the Transferee? From the SIP point of view, there is no *need* to put the original dialog on-hold. I suspect that this operation was included in the flow because in many phones, the first user action would be to place the call on-hold, followed by pushing a transfer button. If the Attended Transfer is implemented by the above call flow, how could we distinguish the operation between Attended Transfer and 3-way conference? Or the hold operation to the Transfer Target has other specific meaning? What device is we? Presumably Transferor device knows which action it is performing. The Target device has no certain way to know what is being done by the Transferor, but in PSTN telophony, it doesn't have that knowledge, either. Dale ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Re: [Sip] About Non-Invite Server Transaction
From: Anil Bollineni [EMAIL PROTECTED] Assume a gateway sends two INVITEs say to two different UASs with the same Via branch parameter to two different users at the same time. It must not do that. See section 8.1.1.7 of RFC 3261: The branch parameter value MUST be unique across space and time for all requests sent by the UA. I understand for retransmitted non-INVITE requests it MUST result sending same response by UAS Assume 200 response to BYE sent by server transaction, and 200 response is lost before it reaches UAC. If it send BYE again, does UAS has to retransmit 200 response? If the second BYE is a retransmission of the first BYE, as you have noted, the UAS is required to send the same 200 response. During transfer if a REFER is sent to UAS and say server transaction say transmit 503 (Declined), due to some temporary failures (e.g. user cant accept more calls), and assume this 503 is delayed. Aftr this failure cleared out, and REFER is retransmitted, and in this case the server transaction sends same error message, even though the user is not busy. First of all, am I mentioning the correct scenario.? If yes, what could be solution. If the second REFER is a retransmission of the first REFER, as you have noted, the UAS is required to send the same 503 response. If the second REFER is a *new* request (which can be determined by the increased CSeq number and the different Via branch parameter), the UAS may examine its situation and return a different response if it chooses. Dale ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] Re: [Sip] About Non-Invite Server Transaction
From: Anil Bollineni [EMAIL PROTECTED] I want to talk about NAT firewall. If two UA's behind NAT firewall generate same branch, and NAT ALG will change the VIA sent-by field to same value. In this case it could result matching same transaction. True. Which is why UAs should generate branch parameters that are unique over all space and time, that is, include some identifier of the UA itself to ensure that no other UA will generate the same branch parameter. I understand for retransmitted non-INVITE requests it MUST result sending same response by UAS What is the purpose behind that. It is to ensure that the retransmission of the request provokes a pure retransmission of the response. In particular (1) the UAC does not attempt to re-execute the request if it receives it twice (which might cause erroneous operation), and (2) if the response to the first request is only delayed, and the UAC receives both the first response and the second response, both responses are identical (otherwise, how would you process them both?). Dale ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] 183 Session Progress with SDP
Dear Sirs, I am a newbie and please forgive me if this post does not below in this list. I have a question that I hope you might be able to clarify for me. Gateway A sends an INVITE to Gateway B with SDP. When B sends back 183 Session Progress with SDP, shouldn't A respond and use the information within the 183 SDP instead of waiting for B's 200 OK SDP? The cdr shows the duration of the call as 72 seconds and the billable second as 43. That is almost 29 seconds before the call is picked up. Shouldn't the 183 SDP from B to A help shorten this post dial delay? Thank you very much for your time! Regards, Pong 192.168.1.209 (A) 10.1.26.125 (B) 192.168.1.61 (A's Media Gateway) | | | | | | 0.000 |INVITE SDP (g729 g711U)| | || | | | | 0.001 | 100 Trying| | || | | | | 5.562 |183 Session Progress SDP (g711U) | || | | | | | | RTP (g711U) | 5.583 | || | | | | | RTP (g711U) | 5.678 | || | | | 28.942 | 200 OK SDP (g711U)| | || | | | | 29.014 |ACK | | || | | | | 29.499 | | RTP (g711U) | | || 71.225 | BYE| | || | | | | 71.226 | 200 OK| | || | ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] 183 Session Progress with SDP
It depends upon what is carried in the 183 SDP. Let us say 183 Is carrying a SDP which connects A to a Media Server and Media Server is just playing an announcement, that your call is proceeding. In that case you would not want to start billing that person after receiving media in 183. 200 OK SDP generally carries the end user's SDP providing the confirmation that the user has accepted the call and is initiating the conversation, so that is the point of time when the billing should start. This is applicable for the case of interworking too, but sometimes at the time of sending 183 the SDP indicates that user has accepted the call, so I think if you provide more detail regarding what SDP is being carried in 183 what is actually happening at the remote end ( Say it is PRI/ISUP/H323/MGCP then what is the level of signaling on the other side, whether at the point of sending 183 User has picked up the phone or not ). one may provide more appropriate suggestion. Billing generally starts when speech path is cut through and speech path to the end-user is cut through normally after 3-way handshake of INVITE 200OK ACK Txn is completed. In between if say 183 carries SDP, then it will depend upon what SDP it carries and whether speech path is being cut through to the end user or to something else. If it is being cut through to the end user, it makes sense to start billing immediately otherwise not. Regards, Indresh K Singh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pong Cavan Sent: Thursday, May 19, 2005 4:13 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] 183 Session Progress with SDP Dear Sirs, I am a newbie and please forgive me if this post does not below in this list. I have a question that I hope you might be able to clarify for me. Gateway A sends an INVITE to Gateway B with SDP. When B sends back 183 Session Progress with SDP, shouldn't A respond and use the information within the 183 SDP instead of waiting for B's 200 OK SDP? The cdr shows the duration of the call as 72 seconds and the billable second as 43. That is almost 29 seconds before the call is picked up. Shouldn't the 183 SDP from B to A help shorten this post dial delay? Thank you very much for your time! Regards, Pong 192.168.1.209 (A) 10.1.26.125 (B) 192.168.1.61 (A's Media Gateway) | | | | | | 0.000 |INVITE SDP (g729 g711U)| | || | | | | 0.001 | 100 Trying| | || | | | | 5.562 |183 Session Progress SDP (g711U) | || | | | | | | RTP (g711U) | 5.583 | || | | | | | RTP (g711U) | 5.678 | || | | | 28.942 | 200 OK SDP (g711U)| | || | | | | 29.014 |ACK | | || | | | | 29.499 | | RTP (g711U) | | || 71.225 | BYE| | || | | | | 71.226 | 200 OK| | || | ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] 183 Session Progress with SDP
Hi, Thank you Indresh for your response. I agree with you that we should not be billing early until a connection has been established. During this call, the billing did not start until we (10.1.26.125) sent 200 OK SDP. The thing I would like to understand is why does it take like 23seconds between 183 Session Progress SDP and 200 OK SDP. I would like to shorten this down to 6-10 seconds. Your input is appreciate it! Here's a trace of the call: No. Time Source DestinationProtocol Info 1 0.00 192.168.1.209 10.1.26.125 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED], with session description Session Initiation Protocol Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Method: INVITE Resent Packet: False Message Header Max-Forwards: 30 Session-Expires: 3600;Refresher=uac Supported: timer To: 15552563645 sip:[EMAIL PROTECTED] SIP Display info: 15552563645 SIP to address: sip:[EMAIL PROTECTED] From: sip:[EMAIL PROTECTED]:5060;tag=3325000742-546077 SIP from address: sip:[EMAIL PROTECTED]:5060 SIP tag: 3325000742-546077 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.1.209:5060;branch=c199c936f231b0d8ebbcd61caa81fffe Contact: sip:[EMAIL PROTECTED]:5060 Content-Type: application/sdp Content-Length: 170 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): NexTone-MSW 1234 0 IN IP4 192.168.1.61 Owner Username: NexTone-MSW Session ID: 1234 Session Version: 0 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.1.61 Session Name (s): sip call Connection Information (c): IN IP4 192.168.1.61 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.1.61 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 17410 RTP/AVP 18 4 8 0 Media Type: audio Media Port: 17410 Media Proto: RTP/AVP Media Format: ITU-T G.729 Media Format: ITU-T G.723 Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.711 PCMU Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 18 G729/8000 Media Attribute (a): fmtp:18 annexb=yes Media Attribute Fieldname: fmtp Media Attribute Value: 18 annexb=yes No. TimeSourceDestination Protocol Info 2 0.00071910.1.26.125192.168.1.209 SIP Status: 100 Trying Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Status-Code: 100 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.1.209:5060;branch=c199c936f231b0d8ebbcd61caa81fffe;received=192.168.1.209;rport=5060 From: sip:[EMAIL PROTECTED]:5060;tag=3325000742-546077 SIP from address: sip:[EMAIL PROTECTED]:5060 SIP tag: 3325000742-546077 To: 15552563645 sip:[EMAIL PROTECTED];tag=as3ea00078 SIP Display info: 15552563645 SIP to address: sip:[EMAIL PROTECTED] SIP tag: as3ea00078 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: sip:[EMAIL PROTECTED] Content-Length: 0 No. TimeSourceDestination Protocol Info 3 5.56228010.1.26.125192.168.1.209 SIP/SDP Status: 183 Session Progress, with session description Session Initiation Protocol Status-Line: SIP/2.0 183 Session Progress Status-Code: 183 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.1.209:5060;branch=c199c936f231b0d8ebbcd61caa81fffe;received=192.168.1.209;rport=5060 From: sip:[EMAIL PROTECTED]:5060;tag=3325000742-546077 SIP from address: sip:[EMAIL PROTECTED]:5060 SIP tag: 3325000742-546077 To: 15552563645 sip:[EMAIL PROTECTED];tag=as3ea00078 SIP Display info: 15552563645 SIP to address: sip:[EMAIL PROTECTED] SIP tag: as3ea00078 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: sip:[EMAIL PROTECTED] Content-Type: application/sdp Content-Length: 164 Message body Session Description Protocol Session Description Protocol Version
RE: [Sip-implementors] 183 Session Progress with SDP
That is not PDD. PDD is time from the iNVITE to any of the following: CANCEL 180 183 2xx 3xx 4xx 5xx Response. So the time between the invite and the 183 is your PDD. The 23 seconds you mention, is how long the phone rangor the time between your 183 and the 200 is your ring time. _ President/CEO Volo Communications, Inc http://www.volocommunications.com (p) 407-389-3232 / (f) 407-389-3233 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pong Cavan Sent: Thursday, May 19, 2005 6:46 PM To: Singh, Indresh; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] 183 Session Progress with SDP Hi, Thank you Indresh for your response. I agree with you that we should not be billing early until a connection has been established. During this call, the billing did not start until we (10.1.26.125) sent 200 OK SDP. The thing I would like to understand is why does it take like 23seconds between 183 Session Progress SDP and 200 OK SDP. I would like to shorten this down to 6-10 seconds. Your input is appreciate it! Here's a trace of the call: No. Time Source DestinationProtocol Info 1 0.00 192.168.1.209 10.1.26.125 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED], with session description Session Initiation Protocol Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Method: INVITE Resent Packet: False Message Header Max-Forwards: 30 Session-Expires: 3600;Refresher=uac Supported: timer To: 15552563645 sip:[EMAIL PROTECTED] SIP Display info: 15552563645 SIP to address: sip:[EMAIL PROTECTED] From: sip:[EMAIL PROTECTED]:5060;tag=3325000742-546077 SIP from address: sip:[EMAIL PROTECTED]:5060 SIP tag: 3325000742-546077 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.1.209:5060;branch=c199c936f231b0d8ebbcd61caa81fffe Contact: sip:[EMAIL PROTECTED]:5060 Content-Type: application/sdp Content-Length: 170 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): NexTone-MSW 1234 0 IN IP4 192.168.1.61 Owner Username: NexTone-MSW Session ID: 1234 Session Version: 0 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.1.61 Session Name (s): sip call Connection Information (c): IN IP4 192.168.1.61 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.1.61 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 17410 RTP/AVP 18 4 8 0 Media Type: audio Media Port: 17410 Media Proto: RTP/AVP Media Format: ITU-T G.729 Media Format: ITU-T G.723 Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.711 PCMU Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 18 G729/8000 Media Attribute (a): fmtp:18 annexb=yes Media Attribute Fieldname: fmtp Media Attribute Value: 18 annexb=yes No. TimeSourceDestination Protocol Info 2 0.00071910.1.26.125192.168.1.209 SIP Status: 100 Trying Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Status-Code: 100 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.1.209:5060;branch=c199c936f231b0d8ebbcd61caa81fffe;received=192.168.1.209;rport=5060 From: sip:[EMAIL PROTECTED]:5060;tag=3325000742-546077 SIP from address: sip:[EMAIL PROTECTED]:5060 SIP tag: 3325000742-546077 To: 15552563645 sip:[EMAIL PROTECTED];tag=as3ea00078 SIP Display info: 15552563645 SIP to address: sip:[EMAIL PROTECTED] SIP tag: as3ea00078 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: sip:[EMAIL PROTECTED] Content-Length: 0 No. TimeSourceDestination Protocol Info 3 5.56228010.1.26.125192.168.1.209 SIP/SDP Status: 183 Session Progress, with session description Session Initiation Protocol Status-Line: SIP/2.0 183 Session Progress Status-Code: 183 Resent Packet: False
Re: [Sip-implementors] 183 Session Progress with SDP
Pong, I was going to ask you why the long delay between the 183 and 200 !, I guess you beat me to it. The trace is helpful but doesn't explain the delay. The field Resent Packet: False might not mean much depending on where the trace was taken and over what transport protocol the signalling was sent. But the network would have to have lost a lot of 200s to account for any significant amount of the 23seconds. It is more likely that this is processing delay in the Asterisk PBX and / or PSTN signalling components. For the complete picture here you need to know what PSTN signalling events occurred for the same call. The 200 OK is not generated and sent until the PSTN ANM (answer)message - which may have taken the full 28+seconds to be recived. The delay can be further explained by what PSTN CPG (call progress) messages were recieved and also what if anything was sent on the early audio from the PSTN. Did the end user here any announcements in this scenario or ringing up until the call completed (receiving end to end audio)?. illustration (not saying this is what happened below!) - network might have terminated on an IVR at the 5sec mark, sent back an Address Complete (ACM) message Atserisk mapped to a 183 with SDP for early media which should be cut-through so the annoucement is heard by the end party. The message plays for 15seconds saying if you didn't press 1 or 2 it would put you through to the operator, you don't so it does, and at 28second mark PSTN sends a ANM back and call completes end to end. Hope the above is at least a little helpful - Wayne. Pong asked: *** Hi, Thank you Indresh for your response. I agree with you that we should not be billing early until a connection has been established. During this call, the billing did not start until we (10.1.26.125) sent 200 OK SDP. The thing I would like to understand is why does it take like 23seconds between 183 Session Progress SDP and 200 OK SDP. I would like to shorten this down to 6-10 seconds. Your input is appreciate it! Here's a trace of the call: No. Time Source DestinationProtocol Info 1 0.00 192.168.1.209 10.1.26.125 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED], with session description Session Initiation Protocol Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Method: INVITE Resent Packet: False Message Header Max-Forwards: 30 Session-Expires: 3600;Refresher=uac Supported: timer To: 15552563645 sip:[EMAIL PROTECTED] SIP Display info: 15552563645 SIP to address: sip:[EMAIL PROTECTED] From: sip:[EMAIL PROTECTED]:5060;tag=3325000742-546077 SIP from address: sip:[EMAIL PROTECTED]:5060 SIP tag: 3325000742-546077 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.1.209:5060;branch=c199c936f231b0d8ebbcd61caa81fffe Contact: sip:[EMAIL PROTECTED]:5060 Content-Type: application/sdp Content-Length: 170 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): NexTone-MSW 1234 0 IN IP4 192.168.1.61 Owner Username: NexTone-MSW Session ID: 1234 Session Version: 0 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.1.61 Session Name (s): sip call Connection Information (c): IN IP4 192.168.1.61 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.1.61 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 17410 RTP/AVP 18 4 8 0 Media Type: audio Media Port: 17410 Media Proto: RTP/AVP Media Format: ITU-T G.729 Media Format: ITU-T G.723 Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.711 PCMU Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 18 G729/8000 Media Attribute (a): fmtp:18 annexb=yes Media Attribute Fieldname: fmtp Media Attribute Value: 18 annexb=yes No. TimeSourceDestination Protocol Info 2 0.00071910.1.26.125192.168.1.209 SIP Status: 100 Trying Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Status-Code: 100 Resent Packet: False Message Header Via: SIP/2.0/UDP
Re: [Sip-implementors] Pingtel Test Proxy Available
Does this Proxy server support Presence? Rgds jaikumar - Original Message - From: Scott Lawrence [EMAIL PROTECTED] To: sip-implementors@cs.columbia.edu Sent: Wednesday, May 18, 2005 11:49 PM Subject: [Sip-implementors] Pingtel Test Proxy Available Pingtel is making available a public proxy for testing purposes at 'interop.pingtel.com'. It is the Pingtel proxy software (based on the sipXpbx open source project: http://www.sipfoundry.org/sipXpbx/ ) with a custom configuration. The configuration is designed to exercise issues we have found are important to interoperability between User Agents and Proxies. Descriptions of how the system is configured and some tests you can perform using it are at http://interop.pingtel.com/ This server is freely available to all, but Pingtel can not provide any free support for diagnosing problems you have with these tests (except at SIPit). I will do my best to make sure that this server stays up, but it may occasionally be unavailable during upgrades (or of course network or power outages). Questions about the software should be taken to the sipx-users or sipx- dev mailing lists at list.sipfoundry.org (http://list.sipfoundry.org/). -- Scott Lawrence, Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162 or sip:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
RE: [Sip-implementors] UPDATE with ANSWER?
Yes Agree, The FAQ creation afford would be appreciated and this will reduce exploration through threads which can be like debate than conclusion and in fact this is quite natural. Also I would be thankful if we maintain agreed upon things which are not cited in RFCs to ascertain the unanimity of all UACs/UASs implementation. Thanks, Bhavik -Original Message- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Thursday, May 19, 2005 7:10 PM To: Chauhan Bhavik-A20762 Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] UPDATE with ANSWER? We really need to create an FAQ about this. A long time ago, probably in the thread you cite, we debated this extensively. It is true that the RFCs are not entirely clear on this, and reasonable people can differ in interpretation of them. But we finally came to some agreement on it. I am quite sure we agreed that UPDATE could *not* be used to send an answer. We ended up with a quite restrictive list of cases for how INVITE, UPDATE, PRACK, and their responses and ACK can be used to convey offer/answer. I was one who originally argued for fewer restrictions. But there were issues with that, and the restrictive approach won out. In practice I don't think the restrictions impose any great burden. Paul Chauhan Bhavik-A20762 wrote: Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/0 06017. html http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017 .html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
