Re: [Sip-implementors] [GRUU] is instance-id mandatory in 2xx of REGISTER?
On Mon, 2010-03-08 at 12:49 +0530, hanifa.mohammed wrote: 5.2. Generating a REGISTER Response When generating the 200 (OK) response to the REGISTER request, the procedures of step 8 of Section 10.3 of RFC 3261 [1] are followed. Furthermore, for each Contact header field value placed in the response, if the registrar has stored an instance ID associated with that contact, that instance ID is returned as a Contact header field parameter. The actual problem is that openIms server returns the public gruu value in 2xx of Register but without '+sip.instance' parameter. Is this ok to proceed processing the GRUU parameters? It appears that openIms is violating section 5.2, in that it returns the public gruu header parameter but not the +sip.instance header parameter. Since the response is incorrect, you have great freedom deciding how to process it. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Ringback on SIP 181 Call forward / 182 Queued
On Tue, 2010-03-02 at 16:49 +0530, Sunita Bhagwat wrote: I'd like to know if a SIP gateway receiving a 181 (Call is being forwarded) or a 182 (call Queued) from SIP peer should play local ringback towards the originating endpoint (say PSTN/ISDN). RFC 3960 mentions early media and ring-back only when a 180 Ringing is received. However I'm seeing a customer scenario involving a Microsoft OCS network forwarding calls to cell phones and sending a 181 to the gateway - expecting the originating gateway to play a ringing tone to calling party. I think it makes sense to play ringing tone and be prepared to play inband media if received, but such a scenario does not seem to be covered in rfc 3960. Appreciate your inputs. Of course, if the terminating UA provides early media, that should be played to the user. But if no early media is arriving (that is, no RTP, not no SDP), the originating UA should provide some useful indication. A true ringing tone shouldn't be used other than for a 180, of course. IIRC, many PSTN systems provide special indicator tones for call forwarding and the like. I seem to remember hearing two short pips for call forwarding operations at times. Perhaps you could use a tone like that for 181 and 182? In the situation you describe, I assume that a 180 arrives at the originating UA (due to ringing of the destination cell phone) within a few seconds after the 181. So two pips (meaning please stand by) for the 181 would be followed by ringback (for the 180). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] FROM URI creation by UA behind SIP proxy
On Mon, 2010-03-01 at 02:33 -0800, Arunachala wrote: One of our UA's creates the FROM URI in its outbound INVITE as follows: 1. If an outbound proxy is configured, puts the proxy's FQDN/ip in the hostname of From URI. 2. If no outbound proxy is configured, puts its OWN ip/FQDN in hostname of From URI. Is this behavior correct? Also, should the UAC who finally receives the request through the outbound proxy bother about the hostname part of the FROM URI? In theory, any URI that ultimately routes to the UA is acceptable. (In some cases, the URI need not even do that, if the caller never receives calls on the UA.) The question to be answered is What URI identifies (in the human sense) the caller? In most cases, the best answer is an AOR which the UA registers -- each registration creates a line appearance on the UA's user interface, and the user selects which line appearance he wants to use as his identity for that call. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Unattended Call Transfer
On Mon, 2010-03-01 at 11:01 +0530, Bajaj, Gagandeep wrote: Hi Dale Thanks for the response. Referring to RFC 5359, my question is regarding F15 containing sipfrag body with SIP/2.0 488 Not acceptable. There is no such F15 in RFC 5359 -- the only F15 in section 2.4 contains a sipfrag body with SIP/2.0 200. Please clarify what section of RFC 5359 you are referring to and what, if any, changes to it you are contemplating. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Unattended Call Transfer
(I assume you are referring to RFC 5359 section 2.4.) On Fri, 2010-02-26 at 14:17 +0530, Bajaj, Gagandeep wrote: Bob sends NOTIFY terminated (15th message) to inform Alice that he has successfully connected with Carol. Beware that it in F15, it is not Subscription-State: terminated that indicates that the transfer was successful, but rather the SIP/2.0 200 OK in the sipfrag body. 1) Why after doing an unattended transfer and sending BYE to Bob, Alice would be interested in the last NOTIFY? Because Alice should not send BYE to Bob, but rather wait for Bob to send BYE (when the dialog to Carol becomes established). 3) If say NOTIFY terminated body contains Failure response to Bob-Carol INVITE, what action Alice takes (generally seen) ?? The UA can show the call to Bob as on hold in the user interface, so that the user can connect to the call and attempt to do something useful. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Should a DTMF event (RFC 2833) be ignored if volume=0 ?
On Fri, 2010-02-26 at 12:26 +0100, Iñaki Baz Castillo wrote: Hi, I've some interoperability problems with a PBX sending DTMF events as follows: RFC 2833 RTP Event Event ID: DTMF Eight 8 (8) 0... = End of Event: False .0.. = Reserved: False ..00 = Volume: 0 Event Duration: 0 This DTMF is not recognized by my softswitch. But the following DTMF from a different PBX is correctly detected: RFC 2833 RTP Event Event ID: DTMF Eight 8 (8) 0... = End of Event: False .0.. = Reserved: False ..00 1010 = Volume: 10 Event Duration: 0 As you report these, the End of Event is false, so there is (should be) a following RTP event with End of Event true and giving the full duration of the event. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple redirect responses in single transaction
On Wed, 2010-02-24 at 21:16 +, Aaron Clauson wrote: Since that would take extra work on the server and the client I'll be a heretic and stick to my 184 info response approach for the time being. It's not much of a contravention of the standard. A UAS can send back as many info responses as it likes and the standard doesn't forbid a UAC from doing some arbitrary processing when it receives an info response, in this case forking a new call. As long as you don't mind requiring the UAC to support the non-standard feature. But generally in SIP, even the largest vendors discover that their business benefits if they can use strictly standard UAs. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple redirect responses in single transaction
On Mon, 2010-02-22 at 21:19 +, Aaron Clauson wrote: The problem I have is that the client does not actually know all the redirects at the point the first one is sent. The client has a human user pressing buttons to initiate the redirects and there could be gaps of 1,2,5,10 etc. seconds between subsequent forwards. Uh, yes? The client will return the first 302 when it knows what the first redirection URI is. It will then immediately receive the INVITE with the phase=2 parameter. It will then *wait* to answer that INVITE until it knows what the second redirection URI is. Each time the client provides a 302, causing the upstream proxy to send a fork to a destination, the client receives another INVITE, which it will eventually respond to to provide the next response... Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple redirect responses in single transaction
On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote: I have a scenario where I want a SIP client to be able to generate multiple redirect responses. The redirect responses will be generated based on user actions and will have a variable delay between them. As far as I can see there is no standard's compliant way to achieve that since the first redirect response will end the transaction with the client preventing it from being able to send any further redirects. You should be able to do this in a standard way. First, let us assume that an address of the client (which is acting as UAS in this situation) is sip:UAS. The incoming request is METHOD sip:UAS. Once the client obtains the first redirect URI, sip:DEST1, it responds SIP/2.0 302 Moved Temp/Contact: sip:DEST1/Contact: sip:UAS;phase=2. This causes the requestor to fork to sip:DEST1, but the requestor also forks to sip:UAS;phase=2. The latter request goes back to the client, bit it is tagged so the client knows to proceed with the second phase of processing for the request. Etc. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [Sip] TCP to UDP rtcp media attributes in SDP not passing through nextone
On Fri, 2010-02-12 at 07:33 -0500, Nitin Kapoor wrote: Could anyone please help me out on this scenario. Why it’s not sending the RTCP attribute to my UAC? Is there anything related to standard. Have you checked the configuration of the SBC or asked the SBC's manufacturer? Within SIP, there is no way to predict what the SBC will do. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] rfc3262: PRACK 481 response during race condition with INVITE 2xx
On Mon, 2010-02-15 at 11:16 -0800, Brett Tate wrote: RFC 3262 allows the UAS to send a final response (such as 200 OK) to INVITE within some situations while there are still outstanding unacknowledged reliable provisional response. Is it acceptable to send 481 response for unacknowledged reliable response's PRACK when the dialog still exists? The relevance is mainly associated with somehow trying to communicate unwillingness to fully update the dialog per PRACK's headers/content because of race condition. It doesn't seem right to send a 481 -- after all, the dialog/dialolg-usage that the PRACK is referencing exists and the provisional response it is confirming existed. Why would the UAS want to reject an acknowledgment of a provisional response that it sent? Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Reg. SIP reinvite, UPDATE
On Thu, 2010-02-11 at 10:39 +0530, Bala Murugan wrote: Thanks for your response , but in the call flow I have mentioned , INVITE transaction is completed ,can you look at below flow the 200OK to INVITE has been already sent from UAS to UAC .My question can a UAC send RE-INVITE if the UPDATE request which it already sent is pending for response. Looking at RFC 3311 section 5.1, it appears that that is allowed. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] What does the description about 407 in RFC3261 mean?
On Wed, 2010-02-10 at 20:11 +0900, Couret Tabt wrote: There is a description below about 407 in RFC3261: 21.4.8 407 Proxy Authentication Required This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. SIP access authentication is explained in Sections 26 and 22.3. This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication. Especially, what does the description below mean? ...but indicates that the client MUST first authenticate itself with the proxy. The client, in the re-send of the request, in order to be successful, will have to present credentials for the realm shown in the Proxy-Authenticate or WWW-Authenticate header. The UAC never has to determine the actual identity of the proxy. It does have to determine the realm that the proxy is demanding credentials for, but that is shown in the *-Authenticate header. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Reg. SIP reinvite, UPDATE
On Wed, 2010-02-10 at 18:14 +0530, Bala Murugan wrote: Can a UAC send RE-INVITE , if a response is pending from UAS for UPDATE refresh Request in early dialog . The UAC cannot send a re-INVITE in an early dialog, because its first INVITE has not completed. See RFC 3261 section 14: Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Who may send '407 Proxy Authenticate Response' ?
On Tue, 2010-02-09 at 22:16 +0100, Olle E. Johansson wrote: Oh. That's evil. I new I could count on you to come up with something even more stressful than what I could imagine in my strange SIP mind. We need to remember that for next SIPit. ;-) As a general rule, any observation XYZ can happen only once is false. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regarding escaped characters in response
On Mon, 2010-02-08 at 21:18 +0530, zabi wrote: If the REQUEST_URI/ TO / FROM /CONTACT has escaped sequence, does the response have to have the same escaped sequence or it may have its parsed values. For e.g if the username in sip request had b%...@example.com. can the response have b...@example.com The consensus is that an escape sequence is equivalent to the unescaped character for all purposes (except in contexts where the unescaped character may not appear). See, e.g., RFC 3261 section 19.1.4, item 4: o Characters other than those in the reserved set (see RFC 2396 [5]) are equivalent to their % HEX HEX encoding. So one would expect that in response values that have to be the same as a value in the request, that the two values MAY differ in non-required escaping. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Provision response with require header
On Sat, 2010-02-06 at 21:43 +0530, Rohit Aggarwal wrote: RFC 3261 also says that although Require is an optional header, it must not be ignored if present. In that case, it may be better option to cancel the request. IMO canceling the request is the one thing the UAC should not do. If the UAC disregards the response, it cannot then cancel the request because it received a response that it disregarded. If the UAC processes the response, then why is it canceling the request? Although, of course, no external observer can prove why the UAC canceled the request, and the UAC always has the right to do so (after it receives a response). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Provision response with require header
On Fri, 2010-02-05 at 16:37 -0500, preynold wrote: I have a question regarding appropriate behavior for a UAC when it receives a provisional response containing a Require header with an unrecognized tag. What should the UAC do? Ignore the provisional response? Process the provisional response normally? CANCEL the request? Something else? In RFC 3261 section 8.2.4: Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards- track RFCs. So the UAC should never be in this situation. Ideally, the UAC should log an error of some sort. Whether to process the provisional response as best it can or ignore it is not well-defined by the standards. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] CSeq of retried INVITE
On Fri, 2010-01-29 at 19:30 +0900, OKUMURA Shinji wrote: Consider the following scenario. | INVITE(CSeq:1)| |---| || | 18x | |---| || | PRACK(CSeq:2) | |---| || | 200 OK(PRACK) | |---| || | 415 | |---| || | ACK | |---| || | INVITE(CSeq:2)| |---| | with the same Call-ID | || according to the section 8.1.3.5 in RFC3261, 2nd INVITE SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. therefore, I think the CSeq of 2nd INVITE SHOULD be 2. To be exact, the CSeq of the 2nd INVITE MUST be 2 or higher, and SHOULD be 2. The analysis is messy, and the rules that are needed to make SIP work are not clearly stated in RFC 3261. The principle is that the initial INVITE is part of a preliminary dialog, that is, the sequence of messages with the given Call-Id and from-tag, but no to-tag. Each early (or established) dialog, that is, each sequence of messages with the given Call-Id and from-tag but with a specific to-tag, *continues* the preliminary dialog, from the point of the INVITE that was responded to, but the early/established dialogs are *independent of each other*. Think of them as branches growing out of the trunk of a tree. This interpretation is the only way that allows the (potentially many) UASs to not interfere with each other or with any needed retries of the INVITE. So the 1st and 2nd INVITEs are in the preliminary dialog, and the PRACK is in the early dialog created by the 18x response to the 1st INVITE. Since the 2nd INVITE and the PRACK are not within the same preliminary/early/confirmed dialog, they take their CSeq's from different counters. They both have CSeq 2, because for both of them, the preceding request is the 1st INVITE. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] sip over tcp, message boundary issue
On Wed, 2010-01-20 at 14:22 +0800, LIU Liping wrote: When TCP is used as transport lay for SIP messages. Maybe the SIP Stack can read some data from socket which includes more than one sip message and maybe the SIP stack can read only a part of a sip message. So, now Is it the stack's duty to determine the sip message boundaries by the START LINE and content length? Is there any protocols to regulate the stack's behaviour? Basically, No. TCP does not provide or guarantee any sort of message boundaries. The recipient of SIP over TCP is required to discern the boundaries using the Content-Length headers. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Reason Header in BYE
On Wed, 2010-01-20 at 17:02 +0530, sunil.bha...@wipro.com wrote: I have a doubt regarding Reason Header in BYE request. We can have the different Reason Header in BYE request depending on the call state. Some of the examples are given below: Reason: SIP ;cause=600 ;text=Busy Everywhere Reason: SIP ;cause=580 ;text=Precondition Failure Reason: SIP ;cause=200 ;text=Call Completed Elsewhere My doubt is - what should be the Reason Header if BYE is sent after server transaction times out waiting for ACK? Remember that there is no requirement that a BYE must contain a Reason header. So you could just omit the Reason in this case. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query related to SUBSCRIBE - NOTIFY behavior w.r.t. proxy server
On Mon, 2009-12-14 at 17:43 +0530, Dushyant Dhalia wrote: 1. Does the proxy server have to start a timer for receipt of NOTIFY? No, because the proxy need not be stateful (beyond a single request/response transaction). The UAs are responsible for keeping track of the subscription state. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is SIP reason text required when sending Reason Header?
On Tue, 2009-12-15 at 09:43 -0500, Adam Frankel wrote: Any ideas if this is actually required per RFC [3326] Standard or if the text= portion of the reason header is only optional? The BNF in RFC 3326 clearly shows the 'text' parameter as optional, and I don't see anything in the text of the RFC that modifies the effect of the grammar. For that matter, the 'cause' parameter appears to be optional as well. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER request, connection termination
On Mon, 2009-12-07 at 17:30 -0500, pvall...@csc.com wrote: When will that happen to SBCs..:) Actually, SIP works quite well with SBCs, as long as the SBC does not attempt to restrict what features of SIP are used. Unfortunately, many service providers configure their SBCs not only to perform specific security activities (logging usage, hiding the topology of their networks), they configure them to prevent any SIP usage other than a specifically designated set. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Any real case of a TEL/SIP URI with parameters as user?
On Tue, 2009-12-08 at 00:56 +0100, Iñaki Baz Castillo wrote: I just mean SIP/TEL URI's for two purposes: 1) For user/device SIP identity (I've never seen a SIP AoR containing parameters). 2) The XUI field of XCAP URI (XUI is the AoR of the user whose document we desire). So I could imagine no cases in whise these URI's have parameters (I hope). Let me repeat myself: If your question is Should my system be able to handle SIP URIs with parameters?, the answer is Yes.. Because if you don't, in the next few months, some usage of your system will require it. It's a law of nature. ;-) It may be that in your application you can sensibly remove parameters from such URIs, or allow a lookup to fail (because the URI is not in the form that the database contains). But you do not want to have your application fail in unexpected ways just because a URI contains a parameter in a situation where you couldn't think of a reason for it to have one. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER request, connection termination
On Tue, 2009-12-08 at 23:42 +, Brez Borland wrote: Dale has a point. I was impressed watching talk dedicated to ipv6 where major minds behind ipv6 development seemed to be straight ignorant, or least interested, in the notion of private network implementations such as NAT. their position is that every device should have a public IP. Which in my opinion would be great yes. But NAT is the concept which has many uses as well, and I believe it is not going to go away very soon. some academics are just weird I guess. It is a double-edged sword. The development of the Internet has been dominated by academic types who have strong ideals that are often unrealistic. But on the other hand, the success of the Internet often results from these unrealistic ideals. (The main one being the end-to-end principle.) Successful implementation often means producing good solutions that simultaneously (nearly) adhere to contradictory requirements. Hopefully we come to IPv6 sometime soon. At the latest IETF meeting (in Hiroshima), the meeting hotel Internet services all had global IPv6 routing. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER request, connection termination
On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote: I still wake up every day asking myself how SIP protocol was born assuming there is no NAT... :( How long have you been involved with the IETF? A lot of IETF people hate NATs like the Pope hates Satan. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [Outbound] One device with multiple users - Should inst id be same for all users?
On Thu, 2009-11-19 at 11:49 +0530, hanifa.mohammed wrote: Hi all, It is very common that a single UA stack, in a device, shall be used by many users. In that case, shall all users use a common instance-id? Will it give any trouble, in real time? Pl clarify whether instance-id is an user configuration or UA configuration. Below is an excerpt from RFC5626, that says that instance ID is device specific and not user specific. The instance ID MUST NOT change as the device moves from one network to another. First, note that the sentence you quoted does not refer to user at all. The central question is what is a device, from the point of view of the user. A simple case is a desk telephone, which may have several lines, each with a different AOR. Because the user *thinks* of the telephone as a single device, the registrations and other operations it carries out should use a single instance-id. A software-based telephone application running on a single-user computer is in a similar situation; the user thinks of it as a single device, so it uses one instance-id. Now consider two different software-based telephone applications running on a computer. If they serve two different people, or if they are in now way coordinated with each other, they must use two different instance-ids. It is also conceivable that a single software application could function as *two* telephones, one for each of two different users (given the necessary hardware devices). In that case, the application needs to partition its activities into two groups, one for each user, and use a separate instance-id for each group. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can we send port=0 in Req-URI?
On Thu, 2009-11-19 at 14:47 +0800, Zhaoning Jiang wrote: SIP gurus, Please help identify this issue. Do Standard allow send Port=0 with FQDN in Req-URI? like t...@icscf-stdn.xxx.com:0 ? I went through RFC3261 and did not find answers. The difficulty is that port 0 is a perfectly valid port for both TCP and UDP (see RFC 768 and RFC 793) but that many TCP/UDP stacks do not handle the specification of port 0 correctly (e.g., the Berkeley sockets interface, which uses a port number of 0 to designate an unspecified port). Hence, although port 0 is technically valid, one should avoid using it, as any operation with it is unlikely to work. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Payload Type for V23
On Fri, 2009-11-20 at 14:38 +0530, Siddhartha Singh wrote: I have running test scenario in which there is sip dialogue established them short message (data) is send in V23 format in RTP stream. I have to ckeck for conformance of transmission mode of V23 in RTP packet, We have fixed payload typed for G771 u law and a lab and we can verify this in RTP captures. Please let me know if there is similar fixed payloadtype for V23 transmission in RTP also. (You mean V.23 don't you?) The fixed payload numbers are listed in http://www.iana.org/assignments/rtp-parameters, under Registry Name: RTP Payload types (PT) for standard audio and video encodings - Closed. I don't see V.23 listed there. The fmtp values for use in SDP allocating dynamic payload numbers are listed on the same page, under Registry Name: RTP Payload Format media types. I don't see V.23 listed there either. So you will have to use a private value, like x-V23. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Clarification of Redirect originator
On Mon, 2009-11-30 at 12:32 -0500, Paul Kyzivat wrote: I have a doubt on this. Should this behavior be of stateful proxy or can stateless proxy also do this? In my understanding, a stateless proxy should not do anything on its own and it should actually pass it to UAC. Is this understanding correct or stateless proxies can also do this? In order to fork a request a proxy must be (transaction)stateful. So you are right that a stateless proxy would have to simply forward the 3xx. I believe that with sufficient care, a stateless proxy can be constructed that performs additional forks when it receives a 3xx response, and that this behavior is valid under RFC 3261. But there is no reason that one would want to build such a proxy, since it would be much easier to pass the 3xx response upstream. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Any real case of a TEL/SIP URI with parameters as user?
On Tue, 2009-12-01 at 13:44 +0100, Iñaki Baz Castillo wrote: Hi, if there any *real* case in any SIP core (i.e: IMS) in which a user could have a URI with parameters? IMS is hardly core SIP usage. If your question is Should my system be able to handle SIP URIs with parameters?, the answer is Yes.. Because if you don't, in the next few months, some usage of your system will require it. It's a law of nature. ;-) (I once wrote a parser for a language. The parser (accidentally) restricted comments to 1024 characters. The *second* test program I wrote had a comment that was 1500 characters.) If your system has to interpret a SIP URI, then in general, it should ignore any URI parameters that it does not understand, or if the context does not give any significance to the parameter. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [gruu] Registrar changes the Public GRUU for a refresh - REGISTER
On Wed, 2009-12-02 at 13:14 +0530, hanifa.mohammed wrote: However, a UA MUST be prepared for the public GRUU to change from a previous one, since the persistence property is not guaranteed with complete certainty. So, even for a refresh-REGISTER, the public GRUU may be different. In that case, for all existing sessions that uses the previous Public GRUU, UA must send target-refresh request, to update the contact. Wont the registrar keep the old public GRUU as valid till the user de-registers? There is no guarantee of anything. The safest course of action is the target-refresh that you describe. (Conveniently, if the UA sends a target-refresh request, its previous GRUU contact need no longer be valid for the request to succeed.) But if you expect GRUU changes to happen very infrequently, and are not very concerned about reliability, the UA can simply use the GRUU for all future requests. Currently active calls might fail, but new ones will succeed. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Collision free Ids: Call-ID, icid-value, Session-ID
On Mon, 2009-12-07 at 14:11 +0530, Gaurav Nangla wrote: Is there an approppriate algorithm like the 'Session-ID generation algorithm' proposed in http://tools.ietf.org/html/draft-kaplan-sip-session-id-02, for the Call-ID header and icid-value (P-Charging-Vector) param. If another developer attempts to generate an id (vis-a-vis the Call-ID header and icid-value (P-Charging-Vector) param) using a different algorithm than the one I've cooked up, I'll have collisions with their ids, i.e. they will no longer be globally unique. As long as the identifier you generate has at least 64 bits of statistically random information, then the probability of one of your identifiers colliding with *any* identifier that another system creates (according to *any* method) is = 2^-64. According to the birthday paradox, if you create a set of such identifiers, it will have to contain 2^32 of them before there is a reasonable chance of any collision. The Kaplan draft proposes to use 128-bit random identifiers, which changes those numbers to 2^-128 and 2^64, respectively. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER request, connection termination
On Mon, 2009-12-07 at 21:11 +0100, Iñaki Baz Castillo wrote: El Lunes, 7 de Diciembre de 2009, Dale Worley escribió: On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote: I still wake up every day asking myself how SIP protocol was born assuming there is no NAT... :( How long have you been involved with the IETF? A lot of IETF people hate NATs like the Pope hates Satan. Does it mean that RFC 3261 exists prior to NAT? XD Not at all. But the fact that RFC 3261 ignores NATs is not accidental or an oversight. Only after SIP became popular in real situations did people work out how to make it work with NATs. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Proxy-Authorization in initial INVITE
On Wed, 2009-11-11 at 18:35 +0530, Ayyanar PK wrote: I don't want to receive 407, instead I want to send Authorization credentials in the initial itself so that the proxy allows the call. Please read RFC3261 section referred below. In that case what are the parameters to be sent in ProxyAuthorization header in initial invite. There is no guaranteed way to construct a Proxy-Authorization header in an initial invite that will be accepted. This is because the header must include a nonce value that the proxy considers acceptable. You are guaranteed to get an acceptable nonce value in the 407 response. But since the proxy can make the valid nonce values dependent on the time and the Call-Id of the request that contains the header, the UAC cannot always predict what would be a valid nonce value. For example, the sipXecs open-source PBX system calculates nonces based on the Call-Id, the from-tag, the current time, and a secret value. Thus, the UAC cannot use a nonce from one dialog in another dialog, and it cannot construct nonces itself. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Maximum size of MIME body?
On Fri, 2009-11-13 at 10:56 +0800, Tsunghao Lee wrote: I have a question about maxinum size of MIME body in SIP MESSAGE. There does not seem to be a defined maximum size. But there is a response code (513) for reporting that a request's size is larger than the UAS can process. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] query in contact
On Sat, 2009-11-14 at 19:57 +0530, Shamik Saha wrote: If there is a contact address that contains an octothorpe # as a prefix,is that a valid contact,the contact is of the form contact : sip:#1...@192.168.123.123:5060 Check the BNF in section 25.1 of RFC 3261. In this case, the user-part is specified by the production user, and you can trace the productions to see that '#' will not be generated by user. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why Via in SIP is the opposite to Via in HTTP(RFC 2616)?
On Fri, 2009-10-23 at 11:15 +0100, Attila Sipos wrote: interesting. Spotter's badge for you! Indeed! I suspect that SIP changed it because it is best to have to most important headers at the top - less time to parse down? I think that was the idea. Consider this sentence from section 7.3.1: However, it is RECOMMENDED that header fields which are needed for proxy processing [...] appear towards the top of the message to facilitate rapid parsing. I've never heard of any implementation that does not do at least preliminary parsing of every header, though. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] An important query regarding SIP call estb
On Thu, 2009-10-15 at 13:54 +0530, Bitan Kundu wrote: Should a SIP call get established if the username (Authorization OR Proxy-Authorization header) and the userinfo portion of the 'From' uri is different? Please point to the RFC section if anywhere it is mentioned. There is no single answer. The authentication username shows the user whose authority is being used to send the request. The From URI tells who is the originator of the request. In most cases these will be the same, but I don't think there is any requirement that they be the same. In any case, use the authentication username to determine if the request should be allowed. (In the sipXecs open-source PBX, the From URI is ignored completely, and only the authentication username is used to determine if a request is allowed.) Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] New Version Notification for draft-worley-instrument-identification-00
I've written up an internet-draft describing how the sipXecs open-source PBX identifies which telephone makes each registration, which allows us to obtain information about specific telephones rather than about AORs. For example, SUBSCRIBE sip:~~in~deadb...@example.net will get the complete dialog status for the telephone with MAC address DEADBEEF, even if the AORs that appear on it appear on other telephones. Also, there are some problems with this method so we are looking for input on better methods to accomplish this. In particular, we'd like to classify registrations by looking at the +sip.instance parameters on the Contact, but there are a number of difficulties with that, mostly around the fact that the sysadmin would have to key UUIDs into the provisioning system, and that is really tedious. Dale On Sun, 2009-10-18 at 09:50 -0700, IETF I-D Submission Tool wrote: A new version of I-D, draft-worley-instrument-identification-00.txt has been successfuly submitted by Dale Worley and posted to the IETF repository. Filename: draft-worley-instrument-identification Revision: 00 Title: Identifying Individual Telephone Instruments in SIP Creation_date: 2009-10-18 WG ID: Independent Submission Number_of_pages: 18 Abstract: When requesting and reporting dialog status in SIP, users often want to know the status of a particular telephone instrument, rather than the status of an Address of Record (AOR). The architecture of SIP makes it difficult to obtain the status of a telephone instrument in a way that is convenient for use in common situations, in particular, in an organization's PBX. This document describes a method for identifying which telephone instrument is making each registration request that is convenient to deploy in PBXs. This information can be used to obtain the status of individual telephone instruments. Unfortunately, although the method works well in practice, it violates separation of concerns by carrying instrument identification information in an authentication-related field. This draft includes a preliminary discussion of better ways to identify instruments. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] New Version Notification for draft-worley-instrument-identification-00
On Mon, 2009-10-19 at 16:51 -0400, Dale Worley wrote: I've written up an internet-draft [...] It can be obtained at http://www.ietf.org/id/draft-worley-instrument-identification-00.txt Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] An important query regarding SIP call estb
On Mon, 2009-10-19 at 22:54 +0200, Iñaki Baz Castillo wrote: Does it means that a request with From sip:al...@domain.org and credentials with username=bob, realm=domain.org would be accepted by sipXecs and routed to the destination? This means that bob is spoofing the call originator. It is true that one can spoof the call originator. But the philosophy we take is that the From and To headers (other than in REGISTERs) are documentation, and not to be taken as reliable. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] People with experience in SIP performance metrics wanted
If you have experience in SIP performance metrics, you might want to join the discussion of draft-ietf-pmol-sip-perf-metrics on the IETF working group mailing list p...@ietf.org. That internet-draft is a proposed standard for SIP performance metrics. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] how is answering machine detection handled in SIP ?
On Thu, 2009-10-01 at 10:37 +0200, DE CLERCQ Johan wrote: As we all know, in ISDN you can detect when you go to a voicemailbox of a cellular line by looking for the PROGRES message as defined in Q.931. There is no good way to do this in SIP. However, an answering automaton should identify itself with the automata media feature tag on its Contact header: Contact: sip:u...@pc.example.com;automata See RFC 3840. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Sip-implementors Digest, Vol 78, Issue 13
On Fri, 2009-10-02 at 15:20 +0200, Iñaki Baz Castillo wrote: El Viernes, 2 de Octubre de 2009, Laurent Etiemble escribió: Hello, If you want to test protocol switching, try the Mercuro IMS Client (http://www.mercuro.net/). It supports the ability to switch from UDP to TCP when the packet size exceed ~1300 bytes. Twinkle (GPL softphone for Linux) also implements switching from UDP to TCP whe the packet exceed a configured size (not fixed value but configurable). http://twinklephone.com/ The sipXecs PBX system (LGPL) switches between UDP and TCP based on message size. http://www.sipfoundry.org/ Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] change source port within a SIP transaction
On Tue, 2009-09-29 at 22:50 +0200, Mihaly Zachar wrote: Lets say I get the first INVITE from 10.1.1.1:53000. When I send the ReINVITE to the A leg it sends back the 100 Trying and then the 200 OK from 10.1.1.1:5060. Is this correct ? Can the UAC change port within a SIP transaction ? With UDP transport, I believe it is allowed. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Initial NOTIFY without state information
On Tue, 2009-08-04 at 13:13 +0200, be...@telekom.de wrote: What should a notifier send in its initial NOTIFY if it doesn't have valid state information? As you've described below, the definition of the event package is supposed to contain that information. Do end devices handle NOTIFYs with an empty body properly? A good question. I expect that any subscriber would handle missing bodies sensibly. But it's a complicated question what proper handling might be. What is a neutral state? RfC 3265: 'Documents which define new event packages MUST define this neutral state in such a way that makes sense for their application' If they only would. Eg. RfC 3842 (MWI) doesn't seem to contain any hint about it. A good point -- that's a deficiency in the specs. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [sipcore] Requests sent within early dialog -- CSeq mgmt
On Wed, 2009-08-26 at 17:10 -0400, Szilagyi, Mike wrote: I’ve not been able to find definitive text regarding this issue so I’m hoping someone can provide clarification. If a request (INFO or UPDATE) is sent on a dialog in the early state, how are the CSeq numbers managed by the UAS. Here’s an example to demonstrate my confusion: The model is that a CANCEL is not an independent transaction from the INVITE, in the way that the UPDATE is an independent transaction from the INVITE. Indeed, CANCEL isn't even routed the same way that the UPDATE is. A CANCEL transaction is sort of a second half of the INVITE transaction that it is canceling. That is why the CANCEL has the same CSeq as the INVITE. (Also, your example shows the UPDATE being sent by the UAC before it receives a non-100 response. That can't be done, since the UAC doesn't know the to-tag to use; there isn't an early dialog established at that point.) Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SUBSCRIBE 202 and 407
On Tue, 2009-09-29 at 15:32 +, Scott Lawrence wrote: On Mon, 2009-09-28 at 16:05 +0530, Thomas george wrote: Hi, In case the Authentication takes more time for a SUBSCRIBE request, Can I first send 202 response to the SUBSCRIBE request and later send 401? No - proxies will not forward the second response because the transaction is complete. You need to send a NOTIFY to the accepted dialog with a Subscription-State of terminated (and some nice explanatory text would be good too). Immediately after sending the 202, the notifier must send a NOTIFY, but it can use Subscription-State: pending to indicate that the subscription has been fully approved by the notifier. If the notifier eventually decides to reject the subscription, it would send another NOTIFY with Subscription-State: terminated. If you are using SIP authentication as a preliminary permission check, you would apply that first, to the initial SUBSCRIBE. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Constructing an ACK request (non 2XX based) in a stateless case
I see in RFC 3261 saction 17.1.1.3, titled Construction of the ACK Request. Have you carefully checked your ACK against its specifications? In regard to the example you provide, the 408 response has no to-tag, which is quite strange for any modern SIP device. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regarding Call Transfer
On Wed, 2009-09-23 at 06:19 -0700, Bharat S wrote: In case of a call transfer, when a REFER request is received at Transferee (from Transferor), what is the method carried in the Cseq Header for the INVITE request originated towards Transfer Target? As per RFC 5589 in case of basic call transfer it is shown that the method in the Cseq Header for INVITE request is REFER, where as on other sources it is observed that the method is being sent as INVITE. That is an error in RFC 5589. (I have just reported it to the RFC editor.) The method in the CSeq must match the method in the request. See RFC 3261, section 8.1.1.5. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Contact mismatch in 200 resp for Register req
On Sun, 2009-08-30 at 12:20 +0530, vijay wrote: Hi, If we get different contact in 200 response for Register request, Is it successful registration? If yes, Can we consider the expires(for reg refresh) value present in the Contact? If no, Please suggest, what should we do? If the registrar accepts your registration (by sending a 200 response), then it must list the contact that was in the REGISTER message in a Contact header. So there is an error in the above situation. One possibility is that the registrar is not registering the same URI that the REGISTER message contains -- that is an error, even if the registrar is doing complex tricks to compensate for NATs. In such a situation, the registrar needs to put the provided contact in a Contact header, even if it puts a different URI in the database. The other error possibility is that some intermediate system is rewriting the REGISTER and/or the 200, but doing so incorrectly -- similar considerations apply. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Registrar: Contact matching decisions if NAT fails
On Tue, 2009-09-08 at 23:24 +0200, Thomas Gelf wrote: The problem we were talking about are clients filling the registrars location database with multiple (usually in the range of 3-30) different records. Same UAC, same Call-ID, same username, same (official) IP but changing port in their Contact, usually followed by (equal) line= or uniq= param. Well, the bindings will time out as usual, so if the phone re-registration period is 1/2 of the expiration time that each registration receives, then there will only be 2 records in the database at a time. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] overloading static RTP payload types with dynamic payload types
On Mon, 2009-08-24 at 08:26 -0700, Amy Hwang wrote: Let's say SDP is offered with the following media line: m=audio 12345 RTP/AVP 97 a=rtpmap:97 PCMU/8000 That is, a dynamic payload type of 97 is being used to represent PCMU/8000, which is also mapped to the static payload type of 0 by RFC 3551. If this offer is accepted, then would the resulting RTP stream contain a payload type of 0 or 97? PCMU could only be sent using payload number 97 because the offer does not specify that payload number 0 may be used. A static payload type only specified that *if* the number is listed in the m= line, then there does not need to be an a= line to describe what the codec is for that payload number. However, if the offer is: m=audio 12345 RTP/AVP 0 97 a=rtpmap:97 PCMU/8000 Then either 97 or 0 could be used for sending PCMU. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can EP send media only peer supports
On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote: Additional round trips should be made optional (only for implementations having concurrent codecs limitation). Additionally, why can't the spec be modified (or place in a BCP): 1. to allow only a sub-set (of what is present in the offer) in the answer (or even just one codec) If you mean, Is it allowed to put in the answer only a subset of the codecs that are in the offer, that is allowed now. 2. to place a restrion on the offerer to only use one of the codecs listed in the intersection of answer offer. Some implementations use more than one codec, so that would have to be considered a BCP. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can EP send media only peer supports
On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote: I think answerer can add additional codec G729 here per sec 6.1 of rfc3264 snip The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive /snip However, here comes the inconsistency. When answerer send media, it cannot send G723 packets to offerer per sec 6.1 of RFC3264 snip The answerer MUST send using a media format in the offer that is also listed in the answer, /snip Whereas RFC3264 does not forbid offerer to send G729 packets to answerer per sec 7 snip It MUST send using a media format listed in the answer, and it ***SHOULD*** use the first media format listed in the answer when it does send. /snip I think you've found a mistake in the wording of the RFC. The writers assumed that if the offerer was willing to send G729, then it would have offered to do so. Clearly, the intention is that both the offerer and answerer must use only codecs that have been listed in both the offer and the answer. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] How to handle 183/SDP followed by 180/SDP?
On Mon, 2009-08-10 at 17:52 +0530, Aryan wrote: Actually i am having an issue when 183 is not unreliable , but 180 is reliable. But i have read somewhere that 183 is more preferred over 180, right? No... In general, the answerer may send the answer in some or all of the provisional responses, but it must ultimately send the answer in a reliable response, either a reliable provisional response or a 2xx response. *All of these answers must be the same.* So if you are seeing a conflict between the 183's answer and the 180's answer, the device generating them is malfunctioning. (Unless I've made a mistake.) However if both the 183 and 180 are having different TO tags and different codec lists then its again an issue. then we cannot come to know whether to reject the 180 which is reliable or not? If two provisional responses have different to-tags, then they are part of two different dialogs, and the rules apply to each dialog separately. In this case, the 180 and 183 answers can be different. This does present the UAC with the problem of how to render the two dialogs, for which there is no standard. A common tactic is to check to see if any dialog(s) are providing the media described in the answer(s). If so, all of those media streams are mixed together and presented to the user. If no dialogs are providing media, and if a 180 (Ringing) has been received, then a ring tone is presented to the user. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Example correct? (draft-schwarz-mmusic-sdp-offer-answer-examples-00.txt); RE: Revised SDPO/A; RE: codec negotiation
On Mon, 2009-08-03 at 14:03 +0200, Schwarz Albrecht wrote: Right, the draft is very initial, the crucial part is just the SDP example only. As soon as we got agreement that the SDP syntax is correct and inline with SDPCapNeg and SDPMediaNeg, we'll polish the text and update scope, abstract etc. It is extremely hard to determine if a particular SDP example is correct if one does not have a clear description of what the SDP is attempting to accomplish. That is why you want to update the abstract and descriptive text before bringing the question to a general mailing list like SIP-Implementors. After all, most of your readers here don't know what SDPCapNeg, SDPMediaNeg, T.38, and V.152 are, nor have they thought about the usage scenarios that the SDP is intended to support. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Example correct? (draft-schwarz-mmusic-sdp-offer-answer-examples-00.txt); RE: Revised SDP O/A; RE: codec negotiation
On Fri, 2009-07-31 at 15:23 +0200, Schwarz Albrecht wrote: http://www.ietf.org/internet-drafts/draft-schwarz-mmusic-sdp-offer-answer-examples-00.txt Dear SDP Offer/Answer experts! Our draft provides an example in § 4.4.1.3, using the new SDP syntax according revised SDP O/A: SDP Capability Negotiation, draft-ietf-mmusic-sdp-capability-negotiation SDP media capabilities Negotiation, draft-ietf-mmusic-sdp-media-capabilities Before progressing our draft we would appreciate any feedback, comments by the SDP O/A experts. The Abstract isn't very clear. The Abstract just describes the draft as providing offer/answer examples. But I think that the draft is trying to give examples specifically for V.152 and T.38, and it seems that draft-ietf-mmusic-sdp-capability-negotiation and draft-ietf-mmusic-sdp-media-capabilities are essential to handling those situations well. If that is so, the Abstract should make it clear. Otherwise, people won't realize why they want to read the I-D/RFC. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Updating the Route-Set on receiving 407 response
On Thu, 2009-07-30 at 16:01 +0530, hanifa.mohammed wrote: On receiving 407 for the intiail INvITE request, should the Route-set be updated in the caller side? No: Because the request failed, it has no effect on the dialog state. In addition, since the initial request failed, it does not create a dialog (which would have a route-set). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP video Hold
If the far-end UA has set its Contact URI to have +sip.rendering=no, I think that can be safely taken as the far-end has put us on hold. Other than that, if all the media streams are on sendonly or inactive, you could consider the call to be on hold. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Importance of version number in NOTIFY message
On Tue, 2009-07-28 at 19:52 +0530, rishabh wrote: Is it important to change the version number in every communication we have. if not what will be the result. If the contents of the NOTIFY do not change, then the version need not be changed. But if the contents of the NOTIFY are different from the contents of the previous NOTIFY, then the version should be 1 greater than the previous version. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] request-uri for re-subscription
On Tue, 2009-07-21 at 22:50 +0200, Iñaki Baz Castillo wrote: And it is implemented correctly in the sipXecs proxy system (and most likely all other high-quality SIP implementations). I don't understand what you mean, a proxy has nothing to do here: sipXecs also includes a considerable number of subsystems for implementing UAs. In particular, there are SipSubscribeClient and SipSubscribeServer classes -- and they do support forked subscriptions. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Terminating a Refer (Blind Transfer)
On Fri, 2009-07-17 at 18:32 +0100, Ron Bowater wrote: We have a problem with SIP Blind Transfer using REFER where we get the Notify (100) but then we don't receive the Notify (200) within the time that the application is prepared to wait for. What we do at the moment is to send the INVITE to take the call off hold prior to returning to the IVR applications. However, the switch (not sure which type the customer is using) comes back with a 491 In-Progress error response so clearly we have some unfinished work to terminate the transfer request. Question is: How can I kill the outstanding REFER request ? I could send an unSUBSCRIBE but I *think* that this will only stop me receiving an further NOTIFY requests. I don't think that CANCEL or BYE is applicable in this case so how should I go about stopping the REFER immediately ? I don't think there is any defined way to terminate the processing that was started with a REFER. Although it seems the switch is incorrect in rejecting the re-INVITE with 491 -- the original dialog is unaffected until the REFER-stimulated INVITE succeeds. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] request-uri for re-subscription
On Tue, 2009-07-21 at 01:54 +0200, Iñaki Baz Castillo wrote: As I explained in my other mail, parallel forking in subscription is really a corner case. But the logic and code to implement it in the client is really complex. I expect that a vendor cannot spend so much time to implement such an exotic and complex corner case. Forking SUBSCRIBEs is complex, but it is absolutely necessary. For example, it is used in the implementation of call completion features. (See draft-ietf-bliss-call-completion-04.) And it is implemented correctly in the sipXecs proxy system (and most likely all other high-quality SIP implementations). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] One issue in defending TCP retransmission
On Mon, 2009-07-20 at 11:59 +0800, JC wrote: My scenario is as follows, one SIP client sends one fresh SUBSCRIBE to SIP server via TCP, and SIP server sends 200OK back immediately. Unfortunately, SIP client does incorrect thing to retransmit SUBSCRIBE once before it gets final response. Or it is possible that the 200 is lost by the network, and the UAC must retransmit the SUBSCRIBE. In this error case, when SIP server sends 200OK, associated transaction releases immediately. So for retransmitted SUBSCRIBE, transaction layer will regard it as a new msg, not retransmitted one, and will create a new transation. And dialog layer cann't find one matched dialog for retranmited msg because TO tag not match, so maybe will create a new dialog. There is a known bug/deficiency in the description -- the lower levels of the SIP stack in the UAS retain a record of the received SUBSCRIBE and the 2xx response to it for the maximum retransmission time (3 minutes, IIRC). So when the UAS receives the retransmitted SUBSCRIBE (which it can determine by the repeated branch value), the lower levels of the stack retransmit the 2xx response without notifying the application layers of the arrived SUBSCRIBE. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP video Hold
On Thu, 2009-07-16 at 17:53 -0400, Lakshminarayana Jayaprakash wrote: Is there a convention how SIP video terminal should do call hold? Remember that there is no specified concept of hold. Presumably, you put a multi-media call on hold by setting all the streams to sendonly. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Need Info: reg. REFER TO Header
On Thu, 2009-07-09 at 08:07 -0400, Uttam Sarkar wrote: Please see the definition of Refer-To header. 2.1 The Refer-To Header Field Refer-To is a request header field (request-header) as defined by [1]. It only appears in a REFER request. It provides a URL to reference. Refer-To = (Refer-To / r) HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) addr-spec = SIP-URI / SIPS-URI / absoluteURI SIP-URI = sip: [ userinfo ] hostport uri-parameters [ headers ] headers = ? header *( header ) header = hname = hvalue hname = 1*( hnv-unreserved / unreserved / escaped ) hvalue = *( hnv-unreserved / unreserved / escaped ) escaped = % HEXDIG HEXDIG hnv-unreserved = [ / ] / / / ? / : / + / $ In particular, you will see that = and ; are not contained in either hnv-unreserved or unreserved, and so they must be escaped if they appear in the intended value of a 'header'. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Registration - Challenging Question
On Thu, 2009-07-09 at 13:33 +0200, Michael Hirschbichler wrote: UAC Proxy REGISTER 401 Unauthorized (w challenge)-- ---REGISTER (w correct Credentials)- 401 Unauthorized (w challenge)-- (The credentials are correct and the 401 are no retransmissions) How should the client now behave? Should he retry to register using the Digest from the last 401? How often should the client retry until he stops trying to register? The expectation is that an immediate re-REGISTER will not succeed, and that the UA has to wait for some external change. So it should send re-REGISTERS at a slow pace, waiting to detect the external change. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] About Transport Selection in Response
A major difficulty is that the only IP/port/transport that you *know* the sender is listening on is the one specified in the Via. Many if not most SIP elements will properly process a SIP message no matter what port it is received on, but there is no guarantee that the sending element is listening on any other port than the one described in the Via. Since TCP and UDP have separate port-number spaces, you cannot convert a UDP port number into a TCP port number. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Developing SIP application
On Sun, 2009-06-21 at 01:45 +0800, ChunSean wrote: Hi all, I am planning on developing a SIP application on knopflerfish osgi framework. I face some difficulties when developing the program. This program is planned to be able to Writing a SIP application is a great deal of work. I would suggest you start with an existing SIP software phone application and adapt it to your platform. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] same session-id in o= line of offer-answer SDP
On Tue, 2009-06-23 at 11:55 +0530, Dushyant Dhalia wrote: I have a basic query regarding offer-answer model. Why can't/don't UAC UAS use the same session-id in o= line of the SDP? I agree that RFC 4566 define session-id as sess-id is a numeric string such that the tuple of username, sess-id, nettype, addrtype, and unicast-address forms a globally unique identifier for the session, which makes it different for UAC UAS but i want to know what advantage does give it over same session-id as we have same call-id. SDP was designed and standardized before SIP -- see RFC 2327/4566. One requirement of SDP is that the identifying tuples must be different if the SDPs are different. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query in Request URI
On Tue, 2009-06-23 at 16:24 +0200, Iñaki Baz Castillo wrote: 2009/6/23 Sudhir Kumar Reddy sudhir_kuma...@yahoo.co.in: thanks folks for detailed info. can we consider following P-Asserted-identity Header P-Asserted-Identity: Cullen Jennings sip:flu...@cisco.com ; urip=1234 or should we consider following P-Asserted-Identity: Cullen Jennings sip:flu...@cisco.com; urip=1234 Note that while spaces are allowed around the ; that introduces a header parameter, they are *not* allowed around the ; that introduces a URI parameter. So the above header must be written: P-Asserted-Identity: Cullen Jennings sip:flu...@cisco.com;urip=1234 Any response / reference is higly appreciated You are insiting too much in something that has no response. BTW: a) P-Asserted-Identity: Cullen Jennings sip:flu...@cisco.com;urip=1234 urip is NOT a SIP URI parameter, but a *header* parameter. b) P-Asserted-Identity: Cullen Jennings sip:flu...@cisco.com;urip=1234 In this case urip is a SIP URI parameter. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 100Rel from UAS
On Wed, 2009-06-17 at 17:10 +0400, Kashin Mihail wrote: Hi, everybody! Is it legitimate for UAS to request reliable provisional response option after receiving INVITE without Required or Supported headers. In my case the flow is like this Inv (no 100Rel*)- -100 Trying - 180 Trying (no 100Rel) ** -INFO (Required:100Rel) 200OK(no 100Rel) * - Means no 100Rel indication in the message ** - At this moment UAS (which is actually a B2BUA) establishes a session with another proxy where it uses 100Rel and now it is trying to back-enable 100Rel in our call leg. So is it OK for UAC to answer 200OK to INFO without 100Rel indication? Or should it send 200OK with Req:100Rel and then initiate reliable prov. Response procedure? First, there is no reason to consider 100rel to be a feature of the dialog or call leg. In principle, it is applied to each request individually. In practice, the only requests that get provisional responses (other than 100) will be INVITEs that establish dialogs. So there is no reason to consider 100rel except in the context of an initial INVITE. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Endpoing Disconnection
On Thu, 2009-06-11 at 15:11 +0600, Manoj Priyankara [TG] wrote: Let us imagine that UAC's A and B are in a call and due to a network connectivity problem, user A disconnects without sending any message to the UAS. Then the UAS still thinks that UAC A is alive. Of course if we have SIP OPTIONS kind of keep alive message then after sometime UAS can come to know that UAC A has not accessible and release the call. But if there is no such mechanism, how to handle this situation? Eventually user B will hang up, which will clear the state in UA B. Since there is no state contained in the network between the UAs, the network does not care whether the call is properly torn down or not. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Endpoing Disconnection
On Fri, 2009-06-12 at 22:38 +0600, Manoj Priyankara [TG] wrote: In this case UAC B should have a mechanism to release the call leg by observing RTP (or some other protocol than SIP) and then of course UAS can release the session. This seems to be a possible way to handle the situation if the both users are SIP end points. But what would happen if the B party is a legacy subscriber connected via a H.248 or MGCP media gateway ? The B party won't hear anything, and will hang up! Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating Call Waiting in a 1XX response
On Wed, 2009-06-10 at 15:01 -0400, Simon Perreault wrote: Iñaki Baz Castillo wrote, on 2009-06-10 14:49: Hi, calling today to a cell phone I've seen in my mobile screen: Call waiting in the other side Does something similar exist for SIP? Isn't this exactly what code 182 is for? I think you're right: 21.1.4 182 Queued The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, 5 calls queued; expected waiting time is 15 minutes. The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call. And a UAC might want to display the reason phrase, so you could use SIP/2.0 182 Call waiting Another option would be a new response code: 184 Call-Waiting but it would be very complex to make it work with existing devices which basically expect 180 and 183. Any UA must be prepared to receive any 1xx response and perform adequately. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating Call Waiting in a 1XX response
On Wed, 2009-06-10 at 21:13 +0200, Iñaki Baz Castillo wrote: Yes, it could reply a 182 with SDP but, how many today's devices would render the SDP in a 182 response? They all should. That's a central tenet of SIP design -- there is a default behavior for each class of responses that a device should use if it does not specifically understand the response code. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating Call Waiting in a 1XX response
On Wed, 2009-06-10 at 21:22 +0200, Iñaki Baz Castillo wrote: El Miércoles, 10 de Junio de 2009, Dale Worley escribió: And a UAC might want to display the reason phrase, so you could use Do you mean that the UAC could display the reason phrase in *English*? IMHO a standarized code or string should be needed for this instead of a custom string in English. Strictly speaking, the UAC would display the reason phrase in whatever language the reason phrase is written in. And since SIP uses Unicode consistently... Try http://www.evertype.com/standards/csur/tengwar.html or http://en.wikipedia.org/wiki/List_of_Unicode_characters#Dingbats Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SRTP key transmission
On Sat, 2009-06-06 at 12:31 +0200, Iñaki Baz Castillo wrote: Hi Dale, please don't take me wrong but that sounds too much exotic for me and I don't expect a SIP device being so clever in the next 25 years XD I wouldn't be surprised if the peer-to-peer SIP people use such a scheme. After all, it is pretty much what PGP-encrypted e-mail does, it doesn't protect the transit path, but rather ensures that the only recipient that can read it is the intended one. The deficiency of such a system for telephony is that in many cases, one is not communicating with a known individual, but rather with a person whose significance is their role in an organization. So the caller does not possess a key for the ultimate callee. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP in Session Refresh Request
On Tue, 2009-06-02 at 03:39 -0700, Radha krishna wrote: What should be the SDP in the following scenario. 1) UA1: Send INVITE with 3 codec's. A, B and C. 2) UA2: Received 200 with Codec A. 3) UA1: Session timer expired. 4) UA1: Sending Re-INVITE what should SDP contain? According to RFC we should not change SDP's, so o-line version MUST be same as initial INVITE, What about Codec? It should have A, B and C or just A. I think it should contain all three A, B and C right? One detail that nobody has mentioned: If the o-line in the SDP is the same as that in a previous SDP, the SDPs must be *identical*. But there is no requirement in any of these scenarios that the SDP must be the same as any previous SDP, which would require that the o-line be different. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SRTP key transmission
On Tue, 2009-06-02 at 18:14 +0200, Iñaki Baz Castillo wrote: Anyhow, it seems that before securing the media transmission, it makes sense to also secure the signalling. Since TLS secures the signalling it allows the secure tranmission of master key for SRTP. This is, with TLS you get all the goals (secure SIP + SRTP). In some circumstances, there isn't a need to secure the signaling. Those circumstances are where the callee has knowledge of who the callee is and possesses a key or identifier of the callee. The caller uses SIP as an unsecure rendezvous protocol, and then confirms the identity of the callee using the key. (This is much simpler to implement, and even to define, that secure signaling.) Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Subscription is done for 'presence'. But NOTIFYrecd with event header 'reg' (or/and) 'presence'. What err resp?
On Mon, 2009-06-01 at 11:58 +0530, hanifa.mohammed wrote: Pl find the snippet from RFC3265: If, for some reason, the event package designated in the Event header of the NOTIFY request is not supported, the subscriber will respond with a 489 Bad Event response. It means that the dialog matching does not include Event header. If the dialog ID matches, but Event package is NOT suppoertd, 489 shall be sent from Subscriber also. Pl clarify. The best response is 481, as the NOTIFY that was received does not match any subscription that was established (as the identity of the subscription includes the event-type). It is possible that a particular subscriber must first sort NOTIFYs based on their Event values, and thus would discover that it does not support 'reg' before it discovers that there is no matching subscription. In that case, a 489 would probably be acceptable. But since the notifier is malfunctioning (rather than experiencing an ordinary operation problem), the only truly necessary requirement is that it returns a 4xx response of some sort. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Signaling SIP-ISDN Gateway.Supplementary Services.
On Sun, 2009-05-31 at 15:03 +0200, Rodriguez Merchan, Pedro Julian wrote: Could you help me about making Gateway ISDN supplementary services betwen SIP and ISDN (Q931/QSIG)? Some work has been done on this, but not a lot. E.g., the IETF Bliss working group has done work on interoperation of call completion. I believe that TISPAN has been working on some of the supplementary services as well. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] is this a valid rtpmap attribute?
On Tue, 2009-05-26 at 09:21 +0300, Brocha Strous wrote: Is the following line valid: a=rtpmap:101 telephone-event/000 What is the meaning of a 0 clock rate? And isn't it supposed to be a number? I tried to find somewhere a BNF specification for RTPMAP attribute lines but only found very general statements. What would be the correct way to parse a RTPMAP line into all its pieces that would account for the different syntaxes? Should the clock rate be treated as a string and not a number? Looking at RFC 2833, especially section 3.5, the rate part of the rtpmap specification means that the time units in the RTP telephone-event packets are at that many per second. E.g., the standard value 8000 means that the timestamps are in units of 1/8000 second. Given that, a rate value of zero is useless. In your case, the standard value is 8000, and what we see is 000, making it extremely likely that the line you see is a typo for a=rtpmap:101 telephone-event/8000 Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Distinguishing Forked and Looped scenarios atSIP proxy
On Wed, 2009-05-13 at 15:30 +0530, Ashwath Kumar wrote: So if proxy is sending 404 not found is it valid behavior of the proxy ? or should we expect 5xx 'loop detected' ? 482 is used for Loop Detected (this request has passed through this proxy before) and Merged Request (a copy of this request from a different fork has passed through this proxy before). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] LWS allowed at the end of WWW-Authenticate field value ?
I believe that we have discovered that the RFC 3261 grammar allows whitespace at the end of (almost) no headers. But people expect that parsers will accept (linear) whitespace at the end of all headers. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 487 after BYE on early dialog
On Tue, 2009-05-12 at 08:47 +0200, Damir Reic wrote: If UAS receives BYE on early dialog and answers it with 200OK, does it have to respond to initial invite with 487 (same as CANCEL was received)? In RFC 3261 section 15.1.2, it says: The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Question on ISUP-SIP mapping on receipt of ACM followed by CPG (Alerting)
On Tue, 2009-05-12 at 14:25 +0530, Kapil Saxena wrote: I have a MGW that has SIP interface towards UE and ISUP towards MSC. For a SIP-ISUP call: 1. MGW receives SIP INVITE from UE and sends IAM to MSC-A. 2. MGW receives backward ACM message with called party status = free from MSC-A. 3. MGW sends 180 Ringing towards SIP UE. 4. Called Party (on MSC-A) rings but does not answer 5. Call is now forwarded by MSC-A (this is the case of call forwarding after alerting the user) towards MSC-B. Thus, MSC-A sends IAM to MSC-B 6. MSC-B sends ACM message with called party status = free towards MSC-A 7. MSC-A transforms it to CPG (Alerting) and sends it towards MGW. 8. My question is: what MGW should do with 2nd CPG (Alerting) message? RFC 3398 (ISUP-SIP interworking) mandates to send out 180 but as MGW has already sent out 180 (see #3 above), so it can not send duplicate 180 with same tag. Certainly, it is legal in SIP to send more than one 1xx message with the same to-tag. As a matter of implementation, the MGW may prefer not to do so, as it may not carry any additional information. More difficulty arises if the offered media from MSC-B is different than the offered media from MSC-A, because that would require that the second 180 have different SDP than the first 180, and that is not allowed if they have the same tags. Another implementation approach would be for the MGW to construct the second 180 using a different to-tag than the first 180. That would give it the freedom to apply different SDP to the second 180. I expect that there are a lot of possible implementations of such an MGW. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialog can be replaced if TransferTarget is the reciepient of dialog (early) during Attendant Call Transfer
On Sat, 2009-05-09 at 10:05 +0530, Vivek Batra wrote: Moreover, does this mean that an Operator initiating Attended Transfer cannot free-up herself since the transfer target is not responding? This would be very taxing in practical world because most of the times, the Operator wishes to execute Attended Transfer but since the transfer target does not respond in time, she frees up herself (by performing the Attendant Transfer activity in ringing state) for receiving other calls. What is the way out? In practice, the solution is for the user agent to perform the transfer in the background by doing nothing until the new call leg is answered, and then sending the REFER that completes the transfer. (This has been understood since at least 2003, when the Pingtel Xpressa phone implemented it.) Although the phone must perform much activity, the user of the phone is freed to do other things. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Question about CALL-ID in Pararell search
On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote: A question about the CALL-ID. 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc. 2. Redirect server sends response 300 Multiples Choices. 3. UAC makes a pararell search sending three INVITES with CALL-ID: ¿abc?. I dont understand why first INVITE and three last INVITES have the same CALL-ID... The three INVITEs generated in step 3 are considered to be forks of the original INVITE from step 1. The reason why this is the best way to organize the operation is that the UAC only wishes to establish one dialog, with whichever of the INVITEs receives a successful response. Since all 4 INVITEs have the same call-id, if (through more forking downstream), one UAS receives two INVITEs derived from them, it can responds to the second INVITE with 482, thus avoiding having the UAS present two copies of the same logical call to its user. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialog can be replaced if TransferTarget is the reciepient of dialog (early) during Attendant Call Transfer
On Mon, 2009-05-11 at 23:06 +0200, Iñaki Baz Castillo wrote: In practice, the solution is for the user agent to perform the transfer in the background by doing nothing until the new call leg is answered, and then sending the REFER that completes the transfer. (This has been understood since at least 2003, when the Pingtel Xpressa phone implemented it.) Although the phone must perform much activity, the user of the phone is freed to do other things. Interesting. And does some phone implement it? (I've never seen it). I call your attention to the sentence I wrote: ... the Pingtel Xpressa phone implemented it. I suspect that if you check other high-quality phones that have been in the market for several years, you will find others. Of course, many low-quality phones with poor software do not handle this case correctly, and customers discover that their calls fail unexpectedly in various circumstances. (I know, because I've had to debug many such cases and report them to the phone vendors.) IMHO this mechanism is really poor. The phone is using a line until the transfer target answers the call. What about simple phones with just 2 lines? Since the intention is to free the phone's user from dealing with the call, any lines that show on the phone's user interface can be released immediately. Of course, the phone software will still have to handle the signaling of these calls, but since SIP is an Internet protocol, there is no intrinsic limitation on the number of calls that a phone can handle at any one time. And in this case, there is no requirement that the phone handle media for *either* of the call legs (even if it is implementing music-on-hold), the phone only handles signaling, which is not computationally demanding. How to explain the human user that a phone line is still busy even if he has already free-up himself? Since the user-interface representation of the lines can be freed immediately, this does not have to be explained, as the user-interface appearance matches the user's mental model (even if it doesn't match reality). This is a really bad design IMHO, and it's obvious why so many vendors have decided not to implement it. I invite you to design a mechanism that works better (but it needs to work correctly in the face of forking). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 400 Bad Request response after 180 Ringing (I?aki Baz Castillo)
On Fri, 2009-05-08 at 11:08 +0530, bharath.rangana...@wipro.com wrote: Let me make the question very clear. - There is NO Proxy/B2BUA in between uac uas. In this scenario can the uas send 400 response after 180 Ringing. Because when the UAS generates 180 Ringing, it means that the received request is correct in terms of syntax(ABNF). It would be quite foolish to assume that there is no proxy between the UAC and the UAS. Even if there is not one in your system now, there may be one next year. There is no reason to assume that the *only* reason that a 400 response can be generated is due to syntax errors in the request. Similarly, there is no reason to assume that because you have received a 180 response, that there are no syntax errors in the request. Let us make the answer very clear: Yes, you can receive a 400 response after you receive a 180 response (with the same to-tag). Your UAC should do something sensible in this situation. Specifically, it is required to consider that the call set-up has failed and that the early dialog is terminated. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialog can be replaced if Transfer Target is the reciepient of dialog (early) during Attendant Call Transfer
On Thu, 2009-05-07 at 12:08 +0530, Rastogi, Vipul (Vipul) wrote: I don't know if sending 487 after 180 is good idea. I have seen following in few places ... If the caller cancels the call while it is ringing, the UAS has no choice but to send a 487 after it sends a 180. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialog can be replaced if Transfer Target is the reciepient of dialog (early) during Attendant Call Transfer
On Thu, 2009-05-07 at 21:44 +0200, Iñaki Baz Castillo wrote: El Jueves, 7 de Mayo de 2009, Vikram Chhibber escribió: I could not think of any useful case for early dialog getting replaced at UAS end. Let me tell an example (real example): - A calls B. - B answers. - B wants to transfer the call to C. - So B puts A on-hold and calls C. - C doesnt' answer in 5 seconds, but B *knows* that C is available (sitting near the phone). - So B does the transfer (pseudo-attendant transfer in fact since B doesn't talk with C). Yes, this is a known problem with SIP. What the phone must do is to *pretend* to execute the transfer, but in fact, it keeps the call from A on hold until the call to C is answered. At that point, phone B then executes the transfer. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialog can be replaced if Transfer Target is the reciepient of dialog (early) during Attendant Call Transfer
On Wed, 2009-05-06 at 10:11 +0530, Vivek Batra wrote: If we correlate the above RFC statement with the Attendant Call Transfer, does it mean that if Transfer Target receives the INVITE (replaces) header and it matches with the early dialog which is not initiated by the transfer target, transfer target should not replace the early dialog and return 481 Call Leg Doesn't Exist. Yes, that is what it means. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialog can be replaced if Transfer Target is the reciepient of dialog (early) during Attendant Call Transfer
On Wed, 2009-05-06 at 17:55 -0700, Vikram Chhibber wrote: I can not think of any reason why RFC did not allow replacement of early dialog at the UAS. The reason that the replacement of an incoming early dialog is not allowed is the complexity that would be introduced if the caller has multiple early dialogs with several UASs. In the attended transfer scenario, consider if the still-ringing call to C was actually ringing on two different phones. Then the Replaces header would have to specify *one* of the two early dialogs, but there would be no way for the executing phone to guess which early dialog was the correct one. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] C-line in SDP
On Mon, 2009-04-27 at 12:12 +0300, Meir Leshem wrote: Does the sender of this SDP message obliged to put the same IP address also in the IP header of the RTP packets it sends to the peer? No, there is no such requirement in RTP, SDP, or SIP. However, some UAs do have such a requirement to prevent SPIT. And with many NAT techniques, it is necessary to send from your advertised receive address. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] redirected reinvite to be sent to which address
On Sun, 2009-04-26 at 12:56 +0200, Iñaki Baz Castillo wrote: A SIP phone *cannot* contact a mailto uri, SIP protocol ends when the 302 Contact is a mailto URI. And there is a specific error code for reporting this situation: 416 Unsupported URI Scheme. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
