Re: [Sip-implementors] 200 OK response to REFER
Oops! It should be 200 OK of REFER *must* be interpreted as receiving 202 Accepted because, fundamentally both mean REFER is successful as it is successful final response. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: Attila Sipos [mailto:attila.si...@vegastream.com] Sent: Friday, April 03, 2009 5:28 PM To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK response to REFER I'm not sure I understand your response. Maybe I could ask my question in another way - what is the difference between: a "200 OK REFER response" and a "202 Accepted REFER response? should they be treated differently? -Original Message----- From: Somesh S. Shanbhag [mailto:somesh.shanb...@mgl.com] Sent: 03 April 2009 11:29 To: Attila Sipos; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] 200 OK response to REFER 200 OK of REFER *must* be interpreted as receiving 200 OK because, fundamentally both mean REFER is successful as it is successful final response. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Attila Sipos Sent: Friday, April 03, 2009 2:43 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK response to REFER Some equipment I have observed issues SIP REFER messages which provoke a "200 OK" response instead of "202 Accepted". "202 Accepted" is well-known and is in RFC3265 but... what is the meaning of a "200 OK" REFER response? Regards, Attila ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 200 OK response to REFER
200 OK of REFER *must* be interpreted as receiving 200 OK because, fundamentally both mean REFER is successful as it is successful final response. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Attila Sipos Sent: Friday, April 03, 2009 2:43 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] 200 OK response to REFER Some equipment I have observed issues SIP REFER messages which provoke a "200 OK" response instead of "202 Accepted". "202 Accepted" is well-known and is in RFC3265 but... what is the meaning of a "200 OK" REFER response? Regards, Attila ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Codec Negotiation using X-Lite
Fundamental thing is PBX must be able to decode the PCMA as well because its fair to switch between the negotiated codecs of both the parties. Since, PBX already knows that X-Lite can send PCMA any point of time, it *must* be prepared to receive it as well. Thanks, Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of SungWoo Lee Sent: Friday, April 03, 2009 6:36 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Codec Negotiation using X-Lite Dear all, I think many of you already experienced this issue when using X-Lite. When my pbx offers with a codec preference of PCMU and PCMA, X-Lite answers back with the same codec preference of PCMU and PCMA. So, at this point, both X-Lite and my pbx know each other's preference, and it is the PCMU. As mentioned in RFC3264 Offer/Answer Model, my pbx shoots PCMU packets, but X-Lite sends PCMA packets. Asymetric RTP transmission. We know that X-Lite can send either PCMU or PCMA as long as it matches with any codec in my pbx's offer. But if X-Lite reveals its codec preference in answer and it is happily matched with the offerer's preference, I think it will be more reasonable to use the matched payload type. What do you think? Lee, Sungwoo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Open Source Presence Server
Try Asterisk. It supports presence package. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Pankaj Munjal Sent: Wednesday, April 01, 2009 10:51 AM To: Sip-implementors Subject: [Sip-implementors] Open Source Presence Server Hello all, Any idea if there is any open source Presence Server available? I know of OpenSIPS, which has Presence module and provides basic presence/XCAP features. But i'm looking for one which alos supports advanced presence features like: - Partial Presence (Publish/Notify) - Filter support. - Subscription to XML docs Any pointers shall be really helpful. Regards, Pankaj ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [dialog presence] Is correct a NOTIFY beforeringing?
I think its fine to send the NOTIFY with early state, since the proxy has replied with 100 Trying. I am assuming that when 480 is received, it will again NOTIFY about the termination status. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz Castillo Sent: Monday, March 30, 2009 8:16 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] [dialog presence] Is correct a NOTIFY beforeringing? Hi, I've a PBX acting also as dialog presence server. Users are not local, they exist in a proxy in front of the PBX. When the PBX (a B2BUA) sends an "INVITE sip:al...@domain" to the proxy, the PBX inmediately sends a NOTIFY to the subscribers for the dialog activity of Alice: early But the fact is that Alice is not registered so the proxy returns "480 Not Registered Now" (before it, the proxy sends the appropiate "100 Trying"). I wonder if the PBX behaviour is correct. Under my understanding, the PBX shouldn't send a NOTIFY with "state=early" until it receives a provisional response from Alice (non 100). Am I right? Please clarify me on it so I could report it to the vendor. Thanks a lot. -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Blind Call Transfer
You can have look at http://tech-invite.com/Ti-sip-service-4.html Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Manoj Priyankara [TG] Sent: Mon 3/23/2009 1:11 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Blind Call Transfer Hi All, Can anyone tell me the exact call flow associated with Blind Call Transfer of SIP ? BR, Manoj ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Registrar behaviour
Oops! I used REGISTER in the place of registrar :) Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Somesh S. Shanbhag Sent: Wed 3/18/2009 11:40 AM To: Avasarala Ranjit-A20990; Rastogi, Vipul (Vipul); sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Registrar behaviour If the REGISTER has authorized the client and finds no bindings in it, may be its case where REGISTER might have been rebooted or some means lost the bindings. So, it can honour the De-Registration easily and send 200 OK for it, so that client will re-REGISTER again. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Avasarala Ranjit-A20990 [mailto:ran...@motorola.com] Sent: Wed 3/18/2009 11:32 AM To: Somesh S. Shanbhag; Rastogi, Vipul (Vipul); sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Registrar behaviour Why do u think Registrar should send 200 OK when it does not find any bindings? Thanks Regards Ranjit -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Somesh S. Shanbhag Sent: Wednesday, March 18, 2009 11:19 AM To: Rastogi, Vipul (Vipul); sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Registrar behaviour It will be good to send 200 OK for that REGISTER. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Rastogi, Vipul (Vipul) Sent: Wed 3/18/2009 11:15 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Registrar behaviour What shall registrar sends if UAC sends REGISTER to remove binding whose binding does not exists on registrar ? Thanks, Vipul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Registrar behaviour
If the REGISTER has authorized the client and finds no bindings in it, may be its case where REGISTER might have been rebooted or some means lost the bindings. So, it can honour the De-Registration easily and send 200 OK for it, so that client will re-REGISTER again. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Avasarala Ranjit-A20990 [mailto:ran...@motorola.com] Sent: Wed 3/18/2009 11:32 AM To: Somesh S. Shanbhag; Rastogi, Vipul (Vipul); sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Registrar behaviour Why do u think Registrar should send 200 OK when it does not find any bindings? Thanks Regards Ranjit -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Somesh S. Shanbhag Sent: Wednesday, March 18, 2009 11:19 AM To: Rastogi, Vipul (Vipul); sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Registrar behaviour It will be good to send 200 OK for that REGISTER. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Rastogi, Vipul (Vipul) Sent: Wed 3/18/2009 11:15 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Registrar behaviour What shall registrar sends if UAC sends REGISTER to remove binding whose binding does not exists on registrar ? Thanks, Vipul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Registrar behaviour
It will be good to send 200 OK for that REGISTER. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Rastogi, Vipul (Vipul) Sent: Wed 3/18/2009 11:15 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Registrar behaviour What shall registrar sends if UAC sends REGISTER to remove binding whose binding does not exists on registrar ? Thanks, Vipul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] About 503 with no "Retry-After"
> There is no SIP PBX/gateway/proxy sending a 503 with "Retry-After" > (this is a "magic" IETF solution that cannot work in real world where > a host *doesn't* know how long it will be unavaliable). > So I expect a more robust behaviours in clients. I think all the > clients supporting RFC 3263 failover don't care about the unusual > "Retry-After" header, and react on a 503 with the failover mechanism > (trying another server). > Am I wrong? Nope! .. I think thats right Somesh EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] About 503 with no "Retry-After"
> If a client receives a 503 with NO "Retry-After" should it try an > alterante server (RFC 3263, SRV and so...)? > Or should it "act as if it had received a 500 (Server Internal Error) > response"? (note that error 500 says nothing aboyt failover). > However, RFC 3263 just mentions 503 for SIP failover. I think it can re-try the request to another server. Somesh EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] DNS query
Yeah thats correct. The A query gives you final IP address. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of sarvpriya Sent: Thu 3/12/2009 3:10 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] DNS query Hi, I am currently implementing RFC 3263. I am using GNU adns library asynchronous DNS resolval. The problem I have is that when I do SRV query, the adns library instead of returning host name present in SRV records, it returns me the resultant IP address after doing A query for the hostname present in SRV record. Is this behaviour normal in real time. Do all DNS servers also do A query before returning SRV records. I know this is not specific to SIP, but I guess those of who have implemented RFC 3263 will know this. thanks very much -- cheers sarvpriya ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] multiple media stream in SDP
Yes, its valid one. Simply because the caller wants to open up two audio streams, received at different audio ports. As callee I think we need to take the two streams separately and answer them. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of wen ren Sent: Thu 3/5/2009 1:41 PM To: Sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] multiple media stream in SDP hi, all my question is: multiple media stream but with same media type appears in SDP, how to do with it? It looks like this: m=audio 49232 RTP/SAVP 98 a=rtpmap:98 L16/16000/2 a=crypto:1 .. ... m=audio 49234 RTP/AVP 98 a=rtpmap:98 L16/16000/2 ... if we receive the INVITE with this SDP, how to negotiate with it? we can chose one of them according to our configuration? am I right? or when we receive this SDP, the last audio media will replase the previouse one? any one can help me? thanks ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regarding custom messages
Thats with *Allow* header. According to RFC 3261, 20.5 Allow The Allow header field lists the set of methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports. Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed. Example: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Venkatesh Sent: Tue 3/3/2009 12:34 PM To: Venkatesh Cc: bnshobh...@huawei.com; sandee...@huawei.com; q...@huawei.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Regarding custom messages To add to my statements how else would you ensure your container is capable of sending/receiving generic requests?!?! Sent from Venky's iPhone On Mar 2, 2009, at 11:00 PM, Venkatesh wrote: > I think you are missing the whole point of the test. Like dale > mentions one can in theory define any method name. All the test is > trying to do is to ensure that the container is capable of > generating an arbitary request. Not sure I understand your concern > with the same. > > Thanks, > Venkatesh > > Sent from Venky's iPhone > > On Mar 2, 2009, at 8:08 PM, NarayanaSwamy > wrote: > >> I understand that this is a guideline/practice we could follow to >> support a >> custom-message. >> How about handling an unknown message (say XYZ)? >> >> In the TCK (for JSR289) one of the test is sending an unknown >> message. Is it >> okay to expect the SIP element handle this unknown message? >> >> NarayanaSwamy A. >> --- >> --- >> --- >> --- >> - >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed >> above. Any >> use of the >> information contained herein in any way (including, but not limited >> to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, >> please >> notify the sender by >> phone or email immediately and delete it! >> >> >> -Original Message- >> From: Dale Worley [mailto:dwor...@nortel.com] >> Sent: Tuesday, March 03, 2009 2:35 AM >> To: narayanasw...@huawei.com >> Cc: sip-implementors@lists.cs.columbia.edu; bnshobh...@huawei.com; >> sandee...@huawei.com; q...@huawei.com >> Subject: Re: [Sip-implementors] Regarding custom messages >> >> On Mon, 2009-03-02 at 17:56 +0530, NarayanaSwamy wrote: >>> HI All, >>> >>> As per RFC 3261 >>> Request-Line = Method SP Request-URI SP SIP-Version CRLF >>> >>> Method: This specification defines six methods: REGISTER for >>> registering contact information, INVITE, ACK, and CANCEL for setting >>> up sessions, BYE for terminating sessions, and OPTIONS for querying >>> servers about their capabilities. SIP extensions, documented in >>> standards track RFCs, may define additional methods. >>> >>> >>> Can anyone pls tell me which RFC defines custom methods in the >>> request >>> URI to be supported by sip elements. >> >> If a method was defined in an RFC, it would not be "custom"! >> >> However, there are conventions for "custom", "private", or >> "extension" >> identifiers that are used in many IETF protocols: >> >> If you want to define an identifier for your own experimental use, >> start it >> with "X", then a word that is your project's name, your company's >> name, or >> even your own name, to provide some "scoping" for the extension, >> such as >> "NORTEL", and then another word which identifies the extension. >> This gives >> results like: >> >> X-NORTEL-RULETEST1 sip:jsr289_...@100.2.2.18:5060 SIP/2.0 >> CSeq: 1 RULETEST1 >> >> If your extension becomes popular enough that multiple projects use >> it in a >> consistent way, change the name to remove the project-name part: >> >> X-RULETEST1 sip:jsr289_...@100.2.2.18:5060 SIP/2.0 >> CSeq: 1 RULETEST1 >> >> This convention can be applied to other element names in protocols. >> >> Dale >> >> >> >> ___ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cu
Re: [Sip-implementors] Regarding custom messages
According to RFC 3261 you can generate 405 if you cannot support the method. 8.2.1 Method Inspection Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of NarayanaSwamy Sent: Tue 3/3/2009 9:38 AM To: 'Dale Worley' Cc: bnshobh...@huawei.com; sandee...@huawei.com; q...@huawei.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Regarding custom messages I understand that this is a guideline/practice we could follow to support a custom-message. How about handling an unknown message (say XYZ)? In the TCK (for JSR289) one of the test is sending an unknown message. Is it okay to expect the SIP element handle this unknown message? NarayanaSwamy A. EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Branch parameter as transaction identifierv/sCseq
RFC 3261 Section 17.1.3 17.1.3 Matching Responses to Client Transactions When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. The branch parameter in the top Via header field is used for this purpose. A response matches a client transaction under two conditions: 1. If the response has the same value of the branch parameter in the top Via header field as the branch parameter in the top Via header field of the request that created the transaction. 2. If the method parameter in the CSeq header field matches the method of the request that created the transaction. The method is needed since a CANCEL request constitutes a different transaction, but shares the same value of the branch parameter. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Attila Sipos [mailto:attila.si...@vegastream.com] Sent: Mon 3/2/2009 2:15 PM To: Somesh S. Shanbhag; priyank luthra; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Branch parameter as transaction identifierv/sCseq When you send the CANCEL, won't the branch be the same as in the INVITE? So I can't see what extra advantage is offered by the CSeq. Can you explain. ____ From: Somesh S. Shanbhag [mailto:somesh.shanb...@mgl.com] Sent: 02 March 2009 08:25 To: Attila Sipos; priyank luthra; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Branch parameter as transaction identifierv/sCseq CSeq method is used to identify the transaction along with branch, when a CANCEL request is processed. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Attila Sipos Sent: Mon 3/2/2009 1:53 PM To: priyank luthra; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Branch parameter as transaction identifierv/sCseq Simply: 1. transaction instance is created and a branch parameter is associated with it 2. the branch parameter is placed into a request 3. response is received with the same branch parameter 4. transaction instance can be destroyed As far as I can tell, you don't need to use CSeq to identify a transaction. I believe branch was not used by UA's in the orignal SIP RFC (RFC2543) so CSeq and Method was originally used to match transactions. However in RFC3261, branch is used by UA's so CSeq is not now needed for transaction matching. Regards, Attila -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of priyank luthra Sent: 02 March 2009 06:50 To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Branch parameter as transaction identifier v/sCseq Hi all, I would like to know why and how is a branch parameter in Via header able to identify a transaction, and if so, why do we need CSeq header to identify a transaction? -- Regards, Priyank ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is
Re: [Sip-implementors] Why ACK is not part of the INVITE transactionfor 2xx reponse, but is part of transaction for non-2xx response?
In some *music on hold* scenarios, the INVITE doesn't carry SDP, while 200 OK contains offer and ACK would contain answer. For a detailed call flow you can look at http://tech-invite.com/Ti-sip-service-3.html In such cases, the ACK would require interaction from TU because it has to decide on codec negotiation etc. So, ACK will be sent to Transport Layer directly, I mean since ACK doesn't have any response, no transaction would be created but rather directly sent to Transport Layer. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: priyank luthra [mailto:priyank.lut...@gmail.com] Sent: Mon 3/2/2009 2:03 PM To: Somesh S. Shanbhag Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Why ACK is not part of the INVITE transactionfor 2xx reponse, but is part of transaction for non-2xx response? Hi Somesh, Could you shed more light on the last line? Whats meant by delayed media scenarios where ACK as a separate transaction is helpful? On Mon, Mar 2, 2009 at 12:55 PM, Somesh S. Shanbhag wrote: > ACK is generated by the TU in case of 2xx is received and directly passed > onto > transport layer for sending. In the case of receiving non-2xx final > responses, the > ACK is generated by the transaction layer itself so, its part of the same > transaction. > > In case of 2xx final responses, ACK can be helpful in the delayed media > scenarios > where-in the TU can negotiate SDP's > > > Somesh > > * Please do not take print out of this e-mail unless its absolutely > necessary * > > > > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of priyank > luthra > Sent: Mon 3/2/2009 12:33 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Why ACK is not part of the INVITE > transactionfor 2xx reponse, but ispart of transaction for non-2xx > response? > > I would like to know that why is ACK not considered the part of INVITE > transaction when 2xx response is received. But when non-2xx response is > received, its considered to be part of same transaction. Why is that? > > > -- > Regards, > Priyank > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > -- > EMAIL DISCLAIMER : This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. Any unauthorised distribution or copying is > strictly prohibited. If you receive this transmission in error, please > notify the sender by reply email and then destroy the message. Opinions, > conclusions and other information in this message that do not relate to > official business of Mascon shall be understood to be neither given nor > endorsed by Mascon. Any information contained in this email, when addressed > to Mascon clients is subject to the terms and conditions in governing client > contract. > > Whilst Mascon takes steps to prevent the transmission of viruses via > e-mail, we can not guarantee that any email or attachment is free from > computer viruses and you are strongly advised to undertake your own > anti-virus precautions. Mascon grants no warranties regarding performance, > use or quality of any e-mail or attachment and undertakes no liability for > loss or damage, howsoever caused. > > -- Regards, Priyank EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Branch parameter as transaction identifierv/sCseq
CSeq method is used to identify the transaction along with branch, when a CANCEL request is processed. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Attila Sipos Sent: Mon 3/2/2009 1:53 PM To: priyank luthra; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Branch parameter as transaction identifierv/sCseq Simply: 1. transaction instance is created and a branch parameter is associated with it 2. the branch parameter is placed into a request 3. response is received with the same branch parameter 4. transaction instance can be destroyed As far as I can tell, you don't need to use CSeq to identify a transaction. I believe branch was not used by UA's in the orignal SIP RFC (RFC2543) so CSeq and Method was originally used to match transactions. However in RFC3261, branch is used by UA's so CSeq is not now needed for transaction matching. Regards, Attila -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of priyank luthra Sent: 02 March 2009 06:50 To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Branch parameter as transaction identifier v/sCseq Hi all, I would like to know why and how is a branch parameter in Via header able to identify a transaction, and if so, why do we need CSeq header to identify a transaction? -- Regards, Priyank ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why ACK is not part of the INVITE transactionfor 2xx reponse, but is part of transaction for non-2xx response?
ACK is generated by the TU in case of 2xx is received and directly passed onto transport layer for sending. In the case of receiving non-2xx final responses, the ACK is generated by the transaction layer itself so, its part of the same transaction. In case of 2xx final responses, ACK can be helpful in the delayed media scenarios where-in the TU can negotiate SDP's Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of priyank luthra Sent: Mon 3/2/2009 12:33 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Why ACK is not part of the INVITE transactionfor 2xx reponse, but ispart of transaction for non-2xx response? I would like to know that why is ACK not considered the part of INVITE transaction when 2xx response is received. But when non-2xx response is received, its considered to be part of same transaction. Why is that? -- Regards, Priyank ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] "expires" field value in REGISTER request
Ideally 400 Bad Request *should* be sent because it in-validates ABNF of SIP. But if registrar honors the expiration somehow, it can reply with 3600 back in 200 OK. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of cool goose Sent: Fri 2/27/2009 11:25 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] "expires" field value in REGISTER request Hi Everyone, If a UA sends a REGISTER request with expires field set to non numeric value say something like this: REGISTER sip:192.168.104.113 SIP/2.0 Via: SIP/2.0/UDP 192.168.104.110:5060;branch=z9hG4bKbab835b91939ee5dd Max-Forwards: 0 From: ;tag=4be5501b2b To: Call-ID: 0f2633d154e734df CSeq: 1 REGISTER Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE,PRACK, SUBSCRIBE, INFO Contact: "SipTool" ; expir...@#$%^*1234567 Content-Length: 0 What would be an ideal response from the registrar for a REGISTER like the one show above? If it responds with 200 OK what do you think should be choose as expiration time? Thanks in Advance, CoolGoose. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Need clarification on handling MESSAGE methodwith in Dialog.
MESSAGE should follow the same rules as for any other non-INVITE in-Dialog messages. And the interpretation is left to the implementation. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of lakshmi Sent: Wed 2/25/2009 11:21 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Need clarification on handling MESSAGE methodwith in Dialog. Hi, We are extending our SIP stack to support for MESSAGE method . Handling MESSAGE outside the dialog is clear. The spec 3428 is not clearly mentioned how to handle MESSAGE with in the dialog. Not cleared with in dialog, on which states MESSAGE request/response must allow? Kindly suggest how to handle MESSAGE with in dialog ? Regards, -Lakshmi ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Max-Forwards header field
Max-Forwards is mandatory in REGISTER request. (Table 2 of RFC 3261) You can reject with 400 Bad Request if Max-Forwards is missing. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of cool goose Sent: Tue 2/24/2009 11:06 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Max-Forwards header field Hi Guys, RFC 3261 states that Max-Forwards is one of the mandatory field in Sec. 8.1.1. Also, it specifies that a UAC must insert Max-Forward header field into each request it originates. Now, my questions is: Is it ok for a registrar to accept a REGISTER request from UAC with out a Max-Forward header field? If not what would be an ideal response? If the registrar is not proxying the register requests will the request validation rules specified in Sec 16.3 apply ? Thanks a Lot, CoolGoose. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] in-active in answer with sendonly in offer
I think the mail difference between recvonly and inactive is recvonly does tell the sender that rtcp reports shall be sent to sender who has sent sendonly. But with inactive you tell to sender that rtcp reports shall not be sent. Somesh Mascon Global * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Anuradha Gupta Sent: Sat 2/21/2009 4:12 PM To: kaiduan xie; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] in-active in answer with sendonly in offer IMO, both the modes in the asnwer are valid. When an offer is recived as Sendonly then the UAS can decide while positively acknowledging the offer either -> only to listen and do not send any data which is recvonly -> do not desire communication in any direction which is inactive In both cases it should not release the resources but apply the desired mode. rgds Anuradha Aricent From: sip-implementors-boun...@lists.cs.columbia.edu [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of kaiduan xie [kaidu...@yahoo.ca] Sent: Saturday, February 21, 2009 1:12 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] in-active in answer with sendonly in offer Hi, all, What is the purpose of putting inactive in answer when receiving a sendonly offer? Rfc3264 Section 6.1 says, "If a stream is offered as sendonly, the corresponding stream MUST be marked as recvonly or inactive in the answer." In rfc5359, recvonly is returned in hold case. Thanks, kaiduan __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Sending 422
And also, since its not UA1's fault to not to support timers, and its between Proxy's UAC and UA2 .. I would say option (2) ( i.e. retry with another INVITE ) would be better. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message----- From: Somesh S. Shanbhag Sent: Wed 2/18/2009 12:45 PM To: Radha krishna; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Sending 422 Its implementation dependent for the proxy .. I think there is absolutely no harm in proxying 422 back to UA1 because anyways UA1 would interpret it as 400, if it cannot understand. But if the proxy takes into consideration the fact that UA1 doesn't support timers, it has two choices. (1) It *may* map the 422 to something like 480 or 503 and send it back to UA1. (2) It *may* even try another INVITE to UA2 with the Session-Expires value of greater than or equal to Min-SE which you receive in 422. ( I believe Min-SE is MUST in 422 ) -Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Radha krishna [mailto:krishna_srk2...@yahoo.com] Sent: Wed 2/18/2009 12:42 PM To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sending 422 Thanks somesh, it can do but in RFC section 9 explicitly says when UAS can send 422 If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy Regards S.Radha krishna ________ From: Somesh S. Shanbhag To: Radha krishna ; sip-implementors@lists.cs.columbia.edu Sent: Wednesday, February 18, 2009 12:16:31 PM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Proxy can forward 422 to UA1. If UA1 doesn't understand 422, it will treat it as 400 and process it. * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Radha krishna [mailto:krishna_srk2...@yahoo.com] Sent: Wed 2/18/2009 11:44 AM To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sending 422 But proxy cannot forward the 422 to UA1 since it is not supporting right? Also it cannot retry with new INVITE if it is not a B2BUA. Regards S.Radha krishna ________ From: Somesh S. Shanbhag To: Radha krishna ; sip-implementors@lists.cs.columbia.edu Sent: Wednesday, February 18, 2009 10:27:16 AM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Since the proxy is call stateful, the INVITE which goes to UA2 shall have Sesssion-Expires field and hence UA2 can reject with 422. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Radha krishna Sent: Wed 2/18/2009 8:18 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Sending 422 Hi Consider the following topology UA1 - Call-stateful-proxy -- UA2 UA1 does not support session timer, Make a call to UA2. Call-stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2 minimum session expires is 900. But in this case INVITE will not contain "support: timer". According section 9, UAS can reject with 422 only if there is a timer tag in supported header If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds. Also UAS cannot increase the session expires duration The UAS MUST NOT increase the value of the Session-Expires header field. What should be the behavior of UAS here? 1) accept the call with 100 seconds? 2) Increase the duration to 900 seconds while sending 200 Ok? Note: Session timer should not be turned-off Regards S.Radha krishna ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and inte
Re: [Sip-implementors] Sending 422
Its implementation dependent for the proxy .. I think there is absolutely no harm in proxying 422 back to UA1 because anyways UA1 would interpret it as 400, if it cannot understand. But if the proxy takes into consideration the fact that UA1 doesn't support timers, it has two choices. (1) It *may* map the 422 to something like 480 or 503 and send it back to UA1. (2) It *may* even try another INVITE to UA2 with the Session-Expires value of greater than or equal to Min-SE which you receive in 422. ( I believe Min-SE is MUST in 422 ) -Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Radha krishna [mailto:krishna_srk2...@yahoo.com] Sent: Wed 2/18/2009 12:42 PM To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sending 422 Thanks somesh, it can do but in RFC section 9 explicitly says when UAS can send 422 If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy Regards S.Radha krishna ____________ From: Somesh S. Shanbhag To: Radha krishna ; sip-implementors@lists.cs.columbia.edu Sent: Wednesday, February 18, 2009 12:16:31 PM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Proxy can forward 422 to UA1. If UA1 doesn't understand 422, it will treat it as 400 and process it. * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Radha krishna [mailto:krishna_srk2...@yahoo.com] Sent: Wed 2/18/2009 11:44 AM To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sending 422 But proxy cannot forward the 422 to UA1 since it is not supporting right? Also it cannot retry with new INVITE if it is not a B2BUA. Regards S.Radha krishna ________ From: Somesh S. Shanbhag To: Radha krishna ; sip-implementors@lists.cs.columbia.edu Sent: Wednesday, February 18, 2009 10:27:16 AM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Since the proxy is call stateful, the INVITE which goes to UA2 shall have Sesssion-Expires field and hence UA2 can reject with 422. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Radha krishna Sent: Wed 2/18/2009 8:18 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Sending 422 Hi Consider the following topology UA1 - Call-stateful-proxy -- UA2 UA1 does not support session timer, Make a call to UA2. Call-stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2 minimum session expires is 900. But in this case INVITE will not contain "support: timer". According section 9, UAS can reject with 422 only if there is a timer tag in supported header If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds. Also UAS cannot increase the session expires duration The UAS MUST NOT increase the value of the Session-Expires header field. What should be the behavior of UAS here? 1) accept the call with 100 seconds? 2) Increase the duration to 900 seconds while sending 200 Ok? Note: Session timer should not be turned-off Regards S.Radha krishna ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained
Re: [Sip-implementors] Sending 422
Proxy can forward 422 to UA1. If UA1 doesn't understand 422, it will treat it as 400 and process it. * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: Radha krishna [mailto:krishna_srk2...@yahoo.com] Sent: Wed 2/18/2009 11:44 AM To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sending 422 But proxy cannot forward the 422 to UA1 since it is not supporting right? Also it cannot retry with new INVITE if it is not a B2BUA. Regards S.Radha krishna From: Somesh S. Shanbhag To: Radha krishna ; sip-implementors@lists.cs.columbia.edu Sent: Wednesday, February 18, 2009 10:27:16 AM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Since the proxy is call stateful, the INVITE which goes to UA2 shall have Sesssion-Expires field and hence UA2 can reject with 422. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Radha krishna Sent: Wed 2/18/2009 8:18 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Sending 422 Hi Consider the following topology UA1 - Call-stateful-proxy -- UA2 UA1 does not support session timer, Make a call to UA2. Call-stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2 minimum session expires is 900. But in this case INVITE will not contain "support: timer". According section 9, UAS can reject with 422 only if there is a timer tag in supported header If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds. Also UAS cannot increase the session expires duration The UAS MUST NOT increase the value of the Session-Expires header field. What should be the behavior of UAS here? 1) accept the call with 100 seconds? 2) Increase the duration to 900 seconds while sending 200 Ok? Note: Session timer should not be turned-off Regards S.Radha krishna ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for lo
Re: [Sip-implementors] Sending 422
Since the proxy is call stateful, the INVITE which goes to UA2 shall have Sesssion-Expires field and hence UA2 can reject with 422. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Radha krishna Sent: Wed 2/18/2009 8:18 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Sending 422 Hi Consider the following topology UA1 - Call-stateful-proxy -- UA2 UA1 does not support session timer, Make a call to UA2. Call-stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2 minimum session expires is 900. But in this case INVITE will not contain "support: timer". According section 9, UAS can reject with 422 only if there is a timer tag in supported header If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds. Also UAS cannot increase the session expires duration The UAS MUST NOT increase the value of the Session-Expires header field. What should be the behavior of UAS here? 1) accept the call with 100 seconds? 2) Increase the duration to 900 seconds while sending 200 Ok? Note: Session timer should not be turned-off Regards S.Radha krishna ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Problem with SDP negotiationwrta-synchronousoffer
Just a clarification .. We can also include a=rtcp: IN IP4 in order to specify different rtcp port ( which may be other than rtp + 1 ) and rtcp address. This is in accordance with RFC 3605 Thanks, Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of shamik.s...@wipro.com Sent: Mon 2/16/2009 5:30 PM To: rohit.aggar...@aricent.com Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Problem with SDP negotiationwrta-synchronousoffer Hi Rohit, Yes you are correct,The actual RTCP report will be sent to the next higher port number,I have just mentioned there what will be in the syntax,but the actual interpretation will be like what you said. Thanks and regards, Shamik Saha Project Engineer Voice Protocols Cell : +91-9886704155 EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ 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 71, Issue 26
Whats the actual question? Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Tapan Kumar Biswal Sent: Fri 2/13/2009 10:29 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sip-implementors Digest, Vol 71, Issue 26 Dear Friends, Can anybody help me, for testing the voice quality in VoIP enviornment ? here are some quality related parameter which we are supporting in our VoIP product. 1. G729 VAD 2. G723 VAD 3. Comfort Noise 4. NTE 5. NTE Event List Size 6. NTE Event List Apart from the above we are supporting all total four Voice codec. ( i.e G7611u & G711a -laws) Thanks & regards Tapan Kumar On 2/12/09, sip-implementors-requ...@lists.cs.columbia.edu < sip-implementors-requ...@lists.cs.columbia.edu> wrote: > > Send Sip-implementors mailing list submissions to >sip-implementors@lists.cs.columbia.edu > > To subscribe or unsubscribe via the World Wide Web, visit >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > or, via email, send a message with subject or body 'help' to >sip-implementors-requ...@lists.cs.columbia.edu > > You can reach the person managing the list at >sip-implementors-ow...@lists.cs.columbia.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. 488 Invalid incoming Gateway SDP: Invalid media (Stephan Steiner) > 2. Re: 488 Invalid incoming Gateway SDP: Invalid media (Dale Worley) > 3. Re: 488 Invalid incoming Gateway SDP: Invalidmedia > (Stephan Steiner) > > > -- > > Message: 1 > Date: Wed, 11 Feb 2009 22:52:49 +0100 > From: "Stephan Steiner" > Subject: [Sip-implementors] 488 Invalid incoming Gateway SDP: Invalid >media > To: > Message-ID: <5644ec80b3894475865ab23a47823...@xpc4> > Content-Type: text/plain; charset="iso-8859-1" > > Hi > > The 488 response is what I get when I connect our office PBX > (Alcatel-Lucent OmniPCX Enterprise 9.0 - AKA OXE) to Microsoft's Office > Communication Server R2 via SIP and call from the OXE to OCS (the reverse > way works just fine. > > I fired up Wireshark and this is what happens between the two systems. > > Actors: caller: 3462 (10.145.26.27) on PBX 10.145.27.72 (OXE) > Mediation Server: 10.145.206.156 (that's the server that translates G.711 > to Microsoft's proprietary RTAudio codec) > > INVITE sip:9...@10.145.206.156 > ;transport=TCP;user=phone > SIP/2.0 > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, SUBSCRIBE, OPTIONS, UPDATE, > INFO > Supported: replaces,timer,100rel > User-Agent: OmniPCX Enterprise R9.0 h1.301.25 > Session-Expires: 1800;refresher=uac > Min-SE: 900 > P-Asserted-Identity: "Tarzis Kessler" > > ;user=phone> > Content-Type: application/sdp > To: ;user=phone> > From: "Tarzis Kessler" > >;tag=a46f56845e2649610af4db5cbb5864ba > Contact: > Call-ID: 01b1aa944c20bcad404dfd3e4cdc8...@10.145.27.72 > CSeq: 1993218136 INVITE > Via: SIP/2.0/TCP > 10.145.27.72;branch=z9hG4bK1b582e17fe997251482147f190c49344 > Max-Forwards: 70 > Content-Length: 316 > > v=0 > o=OXE 1233842864 1233842864 IN IP4 10.145.27.72 > s=abs > c=IN IP4 10.145.26.27 > t=0 0 > m=audio 32514 RTP/AVP 8 0 4 97 > a=sendrecv > a=rtpmap:8 PCMA/8000 > a=ptime:20 > a=maxptime:30 > a=rtpmap:0 PCMU/8000 > a=ptime:20 > a=maxptime:30 > a=rtpmap:4 G723/8000 > a=ptime:30 > a=maxptime:30 > a=rtpmap:97 telephone-event/8000 > > SIP/2.0 100 Trying > FROM: "Tarzis Kessler" > >;tag=a46f56845e2649610af4db5cbb5864ba > TO: ;user=phone> > CSEQ: 1993218136 INVITE > CALL-ID: 01b1aa944c20bcad404dfd3e4cdc8...@10.145.27.72 > VIA: SIP/2.0/TCP > 10.145.27.72;branch=z9hG4bK1b582e17fe997251482147f190c49344 > CONTENT-LENGTH: 0 > > SIP/2.0 488 Invalid incoming Gateway SDP: Invalid media > FROM: "Tarzis Kessler" > >;tag=a46f56845e2649610af4db5cbb5864ba > TO: > ;user=phone>;epid=3CAD90C5CE;tag=43d88de011 > CSEQ: 1993218136 INVITE > CALL-ID: 01b1aa944c20bcad404dfd3e4cdc8...@10.145.27.72 > VIA: SIP/2.0/TCP > 10.145.27.72;branch=z9hG4bK1b582e17fe997251482147f190c49344 > CONTENT-LENGTH: 0 > SERVER: RTCC/3.5.0.0 MediationServer > > Seeing as there is no RTP traffic whatsoever, I figure the Mediation Server > must be objecting to the SDP in the original INVITE. However, at first > glance I don't see anything that's off and the MS support newgroups are a > bust so I'm wondering if somebody here sees something off in that exchange > that could point me towards a solution. > > Thanks in advance > Stephan > > -- > > Message: 2 > Date: Wed, 11 Feb 2009 17:09:07 -0500 > From: "Dale Worley" > Subject: Re: [Sip-implementors] 488 Invalid i
Re: [Sip-implementors] [Sip] Is Contact Header mandatory inREFERmessage?
See Table 2 of RFC 3261 and watch for "Contact" header * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Somesh S. Shanbhag Sent: Wed 2/4/2009 3:21 PM To: Avasarala Ranjit-A20990; sunil.bha...@wipro.com; sanjs...@cisco.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] [Sip] Is Contact Header mandatory inREFERmessage? Contact Header is not *mandatory* for all the SIP messages. Only in few requests and responses the RFC mandates the Contact header. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Avasarala Ranjit-A20990 Sent: Wed 2/4/2009 3:12 PM To: sunil.bha...@wipro.com; sanjs...@cisco.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] [Sip] Is Contact Header mandatory in REFERmessage? Yes, Contact header is required for all SIP Messages. Here after, please post such questions and replies to sip-implementors mail list. Thanks Regards Ranjit From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of sunil.bha...@wipro.com Sent: Wednesday, February 04, 2009 3:08 PM To: sanjs...@cisco.com; s...@ietf.org Subject: Re: [Sip] Is Contact Header mandatory in REFER message? Thanks Sanjay. So, is the Contact Header mandatory for all SIP messages (Response and Requests)? Regards, Sunil From: Sanjay Sinha (sanjsinh) [mailto:sanjs...@cisco.com] Sent: Monday, February 02, 2009 2:18 PM To: Sunil Bhagat (WT01 - Telecom Equipment); s...@ietf.org Subject: RE: [Sip] Is Contact Header mandatory in REFER message? Yes From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of sunil.bha...@wipro.com Sent: Monday, February 02, 2009 11:51 AM To: s...@ietf.org Subject: [Sip] Is Contact Header mandatory in REFER message? Hi, Is it mandatory to have a Contact Header field in REFER message? RFC 3261SIP: Session Initiation Protocol June 2002 8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. RFC 3515 The SIP Refer MethodApril 2003 2. The REFER Method REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2]. A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record- Route logic of that dialog. Regards, Sunil ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in govern
Re: [Sip-implementors] [Sip] Is Contact Header mandatory in REFERmessage?
Contact Header is not *mandatory* for all the SIP messages. Only in few requests and responses the RFC mandates the Contact header. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Avasarala Ranjit-A20990 Sent: Wed 2/4/2009 3:12 PM To: sunil.bha...@wipro.com; sanjs...@cisco.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] [Sip] Is Contact Header mandatory in REFERmessage? Yes, Contact header is required for all SIP Messages. Here after, please post such questions and replies to sip-implementors mail list. Thanks Regards Ranjit From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of sunil.bha...@wipro.com Sent: Wednesday, February 04, 2009 3:08 PM To: sanjs...@cisco.com; s...@ietf.org Subject: Re: [Sip] Is Contact Header mandatory in REFER message? Thanks Sanjay. So, is the Contact Header mandatory for all SIP messages (Response and Requests)? Regards, Sunil From: Sanjay Sinha (sanjsinh) [mailto:sanjs...@cisco.com] Sent: Monday, February 02, 2009 2:18 PM To: Sunil Bhagat (WT01 - Telecom Equipment); s...@ietf.org Subject: RE: [Sip] Is Contact Header mandatory in REFER message? Yes From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of sunil.bha...@wipro.com Sent: Monday, February 02, 2009 11:51 AM To: s...@ietf.org Subject: [Sip] Is Contact Header mandatory in REFER message? Hi, Is it mandatory to have a Contact Header field in REFER message? RFC 3261SIP: Session Initiation Protocol June 2002 8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. RFC 3515 The SIP Refer MethodApril 2003 2. The REFER Method REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2]. A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record- Route logic of that dialog. Regards, Sunil ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing l
Re: [Sip-implementors] Question on Branch parameter usage
Venkat: Comments inline with [SSS] Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of VYANKTESH TADKOD Sent: Tue 2/3/2009 2:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Question on Branch parameter usage Hi All, I am straightaway jumping to the question here If there are 2 UA (UAC's) talking to another UA (UAS) ... a> can both the UAC's use the same branch parameter value in the via header at the same time across different SIP message(s) ? I have a situation where one UA is sending a branch value say A in the top via header of the BYE message and after let say 3-4 sec later I have a INVITE message from another UA with the top via header having the same branch value A. Is this correct? Pls advice. [SSS] Usually the branch parameter prefered to be unique over space and time to prevent conflicts later. So, in most of the implementations its different and unique. In your situation since there is no uniqueness of branch ( both UA's are sending same branch; one in BYE and one in INVITE), I would still process the INVITE because, with BYE the earlier dialog was terminated. Even if I match a transaction to BYE which is in TERMINATED state, I would still entertain receiving the INVITE and processing it. b> In the same context, if the BYE is received by a UA, should the UA (underlying SIP stack) respond to BYE and immediately remove it from transaction table? I see that few of the SIP stack remove the transaction immediately from the transaction table and few of the stack keep the transaction for few secs (~32 sec) before they remove it from the transaction table. Few questions 1> What is purpose of keeping the transaction data (i.e branch ID) in transaction table once the BYE is processed? [SSS] If you have responded to BYE, say 200 OK over UDP, then you would keep the keep the transaction around just to see if any re-transmissions happen because of UDP or network problem and respond with last sent message so that it would not go until the dialog. 2> Is there any standard which mentions about how long it should keep the transaction in the table after it has processed BYE? [SSS] Typically its 64*T1 as per RFC 3261 Thanks and Regards -venkat ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RFC 4028 & Reason header
Yes, Reason-Header can appear in BYE as per RFC3326 " The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. " Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of krishna kalluri Sent: Thu 1/29/2009 10:55 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] RFC 4028 & Reason header Hi, Keep alive mechanisms are described in RFC 4028. If a session refresh is not received before the interval passes then the UA not acting as a refresher sends BYE request to termination the session. Is it allowed and possible to use the Reason header (RFC 3326) in BYE to tell the reason for the termination of the session? If yes what is the best Reason Code? I can think of 487. Regards Krishna ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Monitorizing "line" instead of user/extension
Also, on the same lines, http://www.rfc-editor.org/rfc/rfc3863.txt might also help! * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Simith Nambiar Sent: Thu 1/29/2009 6:44 PM To: Iñaki Baz Castillo Cc: sip-implementors Subject: Re: [Sip-implementors] Monitorizing "line" instead of user/extension > Hi, I wonder which RFC defines the following escenario (AFAIK it's not > feasible with RFC 4235): > > PSTN / SIP provider > | > | > | > | >[ PBX / B2BUA ] > / | \ > / | \ > [ phone A ] [ phone B ] [ phone C ] > > > 1) The PBX receives a PSTN with callerid 12345. > 2) The PBX performs some random algorithm or queue logic so "phone C" > receives the INVITE. > 3) phone A has a dialog subscription to any call from PSTN and > captures the call. > > I can't imagine how to do the step 3. AFAIK RFC 4235 requires a > subscription for an specific AoR, and I cannot know which will be that > AoR since it depends on the PSTN phone calling. Thisis, the INVITE the > PBX sends to phone C would be: > > INVITE sip:c...@ip_c SIP/2.0 > From: > > A "solution" would be phone A subscribing to dialog presence of both > phone B and phone C, but this is not scalable (imagine 100 phones). > > What I mean is that every call capture solutions I've seen are based > on subscription to an specific AoR, so when that AoR receives an > INVITE we can capture it, but what I'm looking for is a subscription > for non specific AoR, but for calls *from* a SIP device (in this case > the PBX). > > How could I achieve it? any document/RFC? > > > [Simith] I'am guessing , if you have all your PBX extensions in your Resource List document, and then SUBSCRIBE to the Resource List SIP URI of the PBX, which has all your extensions , won't you get the Presence of all your extensions ? similarly, For dialog events, probably you could include the package - dialog. Please see http://www.rfc-editor.org/rfc/rfc4826.txt , maybe this could help ! Cheers, Simith > > > > > > Internal Virus Database is out-of-date. > Checked by AVG Free Edition. > Version: 7.1.361 / Virus Database: - Release Date: > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Communication between SIP and Web Services
I think you can look at ParlayX web services which can be used with SIP Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of xvela...@unicauca.edu.co Sent: Thursday, January 29, 2009 5:20 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Communication between SIP and Web Services Hello... Does anybody know about works or projects where is studied and/or developed the communication between SIP and XML technologies found in Web Services? I'm working in this area, especifically in the applicaction layer of IMS, and I would like to know if you have any knowledge about it. Thanks! -- MENSAJE ENVIADO CON WMAIL 1.01 UNIVERSIDAD DEL CAUCA ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regarding Authorization Header Parameter
Look at the following example of Authorization header and its params.
Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value= quoted-string
digest-uri= "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = rquest-uri ; Equal to request-uri as specified
by HTTP/1.1
message-qop = "qop" EQUAL qop-value
cnonce= "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest= LDQUOT 32LHEX RDQUOT
auth-param= auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response= auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
Please look at the auth-param it can be auth-param-name which in turn
may be token (non-quoted) or quoted string.
So, it really depends on the implementation of the softwares. But some
params mandate quotes for example look at
username-value for username param.
So, you would catch parser error for the message which is against ABNF
of RFC 3261 but really depends on implementation.
Some implementations may have relaxed rules for better interoperability
and some don't. So, you may end-up having some gateways
understanding both quoted and non-quoted params.
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
From: friend friend [mailto:sip_qu...@yahoo.co.in]
Sent: Tuesday, January 27, 2009 4:29 PM
To: sip-implementors@lists.cs.columbia.edu; Somesh S. Shanbhag
Subject: RE: [Sip-implementors] Regarding Authorization Header Parameter
Could you please tell me, all the Tokens must not have double quotes and
All the quoted strings must have double quotes?
If RFC doesn't mandate, why some of Gateway not responding for without
double quotes?
-Kannan
--- On Tue, 27/1/09, Somesh S. Shanbhag wrote:
From: Somesh S. Shanbhag
Subject: RE: [Sip-implementors] Regarding Authorization Header
Parameter
To: sip_qu...@yahoo.co.in,
sip-implementors@lists.cs.columbia.edu
Date: Tuesday, 27 January, 2009, 3:08 PM
Strictly speaking according to grammer, most of the known
parameters of
WWW-Authenticate and Authorization are quoted strings. But RFC
doesn't
mandate it should be a quoted string.
For example:
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
nonce-count is a number and not in quotes according to ABNF
-Somesh
* Please donot take the print out of this e-mail unless its
absolutely
necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
Behalf Of friend
friend
Sent: Tuesday, January 27, 2009 2:58 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Regarding Authorization Header
Parameter
Hi folks,
I have a doubt in Authorization & WWW-Authenticate Headers
Parameters...
All the parameters must have double quotes in both headers.
If not sending with double quotes, some of softphone or
Gateway(ITSP)
accepting but some of softphone or Gateway not accepting.
Could you please clarify what are all the parameters must have
double quotes?
Thanks n Advance
Thanks & Regards,
Kannan
Check out the all-new face of Yahoo! India. Go to
http://in.yahoo.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
EMAIL DISCLAIMER : This email and any files transmitted with it
are
confidential and intended solely for the use of the individual
or entity to whom
they are addressed. Any unauthorised distribution or copying is
strictly
prohibited. If you receive this transmission in error, please
notify the sender
by repl
Re: [Sip-implementors] Softphone with Multiple Contact header
I am not sure of sipp on windows. But you must be able to write Authorization header for SIPP in Linux. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * From: friend friend [mailto:sip_qu...@yahoo.co.in] Sent: Tuesday, January 27, 2009 4:20 PM To: Iñaki Baz Castillo; Somesh S. Shanbhag Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Softphone with Multiple Contact header I want to use SIPP as a client. could you please tell me, windows support,If the client SIPP script has Authentication keyword? REGISTER sip:[remote_ip] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port] To: From: Contact: ;transport=[transport] authentication username=joe password=schmo Expires: 300 Call-ID: [call_id] CSeq: 2 REGISTER Content-Length: 0 Please dont mistake me, If i am asking any invalid question? Am new to this domain. -Kannan EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Softphone with Multiple Contact header
Authorization will be in the control of sipp. If you imagine Registrar is your
SIPP, then you can easily simulate.
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
From: friend friend [mailto:sip_qu...@yahoo.co.in]
Sent: Tuesday, January 27, 2009 3:33 PM
To: Iñaki Baz Castillo; Somesh S. Shanbhag
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
Using sipp, can't test the complete Registration flow in Windows Environment
rite.
because the script not supporting dynamic credentials.
Generally Scripts running on Windows. but Authorization not working on windows.
User Registrar
REGISTER -->
<--- 401
REGISTER >
< 200 OK
Thanks for your reply. I will try with asterisk.
--- On Tue, 27/1/09, Somesh S. Shanbhag wrote:
From: Somesh S. Shanbhag
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
To: sip_qu...@yahoo.co.in, "Iñaki Baz Castillo"
Cc: sip-implementors@lists.cs.columbia.edu
Date: Tuesday, 27 January, 2009, 3:12 PM
You can try to configure the 3xx call flows in Asterisk or simply use
sipp tool to act like UAS and generate 3XX responses with multiple contacts.
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
From: friend friend [mailto:sip_qu...@yahoo.co.in]
Sent: Tuesday, January 27, 2009 3:01 PM
To: Iñaki Baz Castillo; Somesh S. Shanbhag
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
Hi Thank for you reply... I would like to know any softphone can able to send
multiple contacts. If yes, please let me know the name of the softphone...
--- On Tue, 27/1/09, Somesh S. Shanbhag wrote:
From: Somesh S. Shanbhag
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
To: sip_qu...@yahoo.co.in, "Iñaki Baz Castillo"
Cc: sip-implementors@lists.cs.columbia.edu
Date: Tuesday, 27 January, 2009, 2:56 PM
REGISTER can have multiple contacts - this is used in the cases where you want
to register at multiple locations with same AOR
Responses for INVITE may have multiple contact addresses (For example,
3xx
responses ) in which case, the proxy can try multiple contacts before it would
give up.(408 or latest received 4xx, 5xx, 6xx response is sent to caller)
The proxy must try in the order of appearance of the contacts subject to the
descending order of contact with highest q= value.
Hope this helps,
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of friend
friend
Sent: Tuesday, January 27, 2009 2:44 PM
To: Iñaki Baz Castillo
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Softphone with Multiple Contact header
I want in REGISTER and INVITE... could you please tell me for 3xx also
Thankn n advance
--- On Fri, 26/12/08, Iñaki Baz Castillo wrote:
From: Iñaki Baz Castillo
Subject: Re: [Sip-implementors] Softphone with Multiple Contact header
To:
Cc: sip-implementors@lists.cs.columbia.edu
Date: Friday, 26 December, 2008, 7:52 PM
2008/12/26 friend friend :
> Dear folks,
> Could anybody please tell me, is any softphone can able to send
multiple contact header? If so, please let me know
Multiple contact headers in REGISTER, INVITE, 3XX response? where exactly?
--
Iñaki Baz Castillo
___
Sip-implementors mailing
list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Add more friends to your messenger and enjoy! Go to
http://messenger.yahoo.com/invite/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
EMAIL DISCLAIMER : This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to whom
they are addressed. Any unauthorised
distribution or copying is strictly
prohibited. If you receive this transmission in error, please notify the sender
by reply email and then destroy the message. Opinions, conclusions and other
information in this message that do not relate to official business of Mascon
shall be understood to be neither given nor endorsed by Mascon. Any information
contained in this email, when addressed to Mascon clients is subjec
Re: [Sip-implementors] Regarding Authorization Header Parameter
Yes, it depends on the type of the param according to ABNF * Please donot take the print out of this e-mail unless its absolutely necessary * From: friend friend [mailto:sip_qu...@yahoo.co.in] Sent: Tuesday, January 27, 2009 3:19 PM To: sip-implementors@lists.cs.columbia.edu; Somesh S. Shanbhag Subject: RE: [Sip-implementors] Regarding Authorization Header Parameter So all Token parameter(QOP,nonce-count) must not have double quotes? -Kannan --- On Tue, 27/1/09, Somesh S. Shanbhag wrote: From: Somesh S. Shanbhag Subject: RE: [Sip-implementors] Regarding Authorization Header Parameter To: sip_qu...@yahoo.co.in, sip-implementors@lists.cs.columbia.edu Date: Tuesday, 27 January, 2009, 3:08 PM Strictly speaking according to grammer, most of the known parameters of WWW-Authenticate and Authorization are quoted strings. But RFC doesn't mandate it should be a quoted string. For example: nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX nonce-count is a number and not in quotes according to ABNF -Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of friend friend Sent: Tuesday, January 27, 2009 2:58 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Regarding Authorization Header Parameter Hi folks, I have a doubt in Authorization & WWW-Authenticate Headers Parameters... All the parameters must have double quotes in both headers. If not sending with double quotes, some of softphone or Gateway(ITSP) accepting but some of softphone or Gateway not accepting. Could you please clarify what are all the parameters must have double quotes? Thanks n Advance Thanks & Regards, Kannan Check out the all-new face of Yahoo! India. Go to http://in.yahoo.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. Add more friends to your messenger and enjoy! Invite them now. <http://in.rd.yahoo.com/tagline_messenger_6/*http:/messenger.yahoo.com/i nvite/> EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance,
Re: [Sip-implementors] Softphone with Multiple Contact header
You can try to configure the 3xx call flows in Asterisk or simply use sipp tool to act like UAS and generate 3XX responses with multiple contacts. Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * From: friend friend [mailto:sip_qu...@yahoo.co.in] Sent: Tuesday, January 27, 2009 3:01 PM To: Iñaki Baz Castillo; Somesh S. Shanbhag Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Softphone with Multiple Contact header Hi Thank for you reply... I would like to know any softphone can able to send multiple contacts. If yes, please let me know the name of the softphone... --- On Tue, 27/1/09, Somesh S. Shanbhag wrote: From: Somesh S. Shanbhag Subject: RE: [Sip-implementors] Softphone with Multiple Contact header To: sip_qu...@yahoo.co.in, "Iñaki Baz Castillo" Cc: sip-implementors@lists.cs.columbia.edu Date: Tuesday, 27 January, 2009, 2:56 PM REGISTER can have multiple contacts - this is used in the cases where you want to register at multiple locations with same AOR Responses for INVITE may have multiple contact addresses (For example, 3xx responses ) in which case, the proxy can try multiple contacts before it would give up.(408 or latest received 4xx, 5xx, 6xx response is sent to caller) The proxy must try in the order of appearance of the contacts subject to the descending order of contact with highest q= value. Hope this helps, Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of friend friend Sent: Tuesday, January 27, 2009 2:44 PM To: Iñaki Baz Castillo Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Softphone with Multiple Contact header I want in REGISTER and INVITE... could you please tell me for 3xx also Thankn n advance --- On Fri, 26/12/08, Iñaki Baz Castillo wrote: From: Iñaki Baz Castillo Subject: Re: [Sip-implementors] Softphone with Multiple Contact header To: Cc: sip-implementors@lists.cs.columbia.edu Date: Friday, 26 December, 2008, 7:52 PM 2008/12/26 friend friend : > Dear folks, > Could anybody please tell me, is any softphone can able to send multiple contact header? If so, please let me know Multiple contact headers in REGISTER, INVITE, 3XX response? where exactly? -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. Cricket on your mind? Visit the ultimate cricket website. Enter now! <http://in.rd.yahoo.com/tagline_cricket_1/*http:/beta.cricket.yahoo.com> EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of virus
Re: [Sip-implementors] Regarding Authorization Header Parameter
Strictly speaking according to grammer, most of the known parameters of WWW-Authenticate and Authorization are quoted strings. But RFC doesn't mandate it should be a quoted string. For example: nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX nonce-count is a number and not in quotes according to ABNF -Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of friend friend Sent: Tuesday, January 27, 2009 2:58 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Regarding Authorization Header Parameter Hi folks, I have a doubt in Authorization & WWW-Authenticate Headers Parameters... All the parameters must have double quotes in both headers. If not sending with double quotes, some of softphone or Gateway(ITSP) accepting but some of softphone or Gateway not accepting. Could you please clarify what are all the parameters must have double quotes? Thanks n Advance Thanks & Regards, Kannan Check out the all-new face of Yahoo! India. Go to http://in.yahoo.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Softphone with Multiple Contact header
REGISTER can have multiple contacts - this is used in the cases where you want to register at multiple locations with same AOR Responses for INVITE may have multiple contact addresses (For example, 3xx responses ) in which case, the proxy can try multiple contacts before it would give up.(408 or latest received 4xx, 5xx, 6xx response is sent to caller) The proxy must try in the order of appearance of the contacts subject to the descending order of contact with highest q= value. Hope this helps, Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of friend friend Sent: Tuesday, January 27, 2009 2:44 PM To: Iñaki Baz Castillo Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Softphone with Multiple Contact header I want in REGISTER and INVITE... could you please tell me for 3xx also Thankn n advance --- On Fri, 26/12/08, Iñaki Baz Castillo wrote: From: Iñaki Baz Castillo Subject: Re: [Sip-implementors] Softphone with Multiple Contact header To: Cc: sip-implementors@lists.cs.columbia.edu Date: Friday, 26 December, 2008, 7:52 PM 2008/12/26 friend friend : > Dear folks, > Could anybody please tell me, is any softphone can able to send multiple contact header? If so, please let me know Multiple contact headers in REGISTER, INVITE, 3XX response? where exactly? -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] How to add sending DTMF functionality to a SIPSoft Phone Application
There are two ways you can send the DTMF. (1) Through SIP - Use INFO messages to communicate the dtmf content (2) Through Media - Use RFC 2833 header in RTP to convey the DTMF and the old POTS way is detecting the DTMF through pulses in PCMA / PCMU. If you are asking about API, that would be specific to SIP Stack or Media Stack you are using. -Somesh * Please donot take the print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Hasini Gunasinghe Sent: Thursday, January 22, 2009 5:34 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] How to add sending DTMF functionality to a SIPSoft Phone Application Hi, I am developing a SIP Soft phone application for windows in C++. I need to send DTMF as user presses keys, to the other party. 1) Is it a SIP Stack functionality or a media stack functionality? 2) Does any one knows about an API that provides application developers to add this functionality to the applications? I apologize if this question is irrelevant to this mailing list. But when I searched for this, I found facts related to both SIP side and media side. Thank you. regards, Hasini. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] best response 305 or 486
Karthik, 486 would be appropriate. We used to return the latest final response in such situations. -Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of karthik karthik Sent: Tue 1/20/2009 10:06 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] best response 305 or 486 Hello, I request clarrification with redirection. Term PCSCF receives 305 with 2 contacts only. Term PCSCF initiates a call to first contact and receives 486. Term PCSCF recurses to the next contact and again receives 486. What is the best response to be forwarded to the originating side? I read the statements from 3261, sec 16.7 and not clear about the decission. sub section 4: If the proxy recurses on all of the contacts in a 3xx response, the proxy SHOULD NOT add the resulting contactless response to the response context. sub section 6: If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. Moreover I prefer forwarding 486 in this case, as some IMS features are based on receipt of 486 like call completion for originating users and call forwarding on busy subscriber for terminating users. Please let me know ur comments. Thanks and Regards, Karthik Prabhu ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP payload in 487.
The max motive I could think of is one will get to know the capabilities if 487 has answer SDP and also there might be remote possibility that the answering with SDP in 487, I doubt if user is opening media channel, in which case, it allows caller to play some terminating announcements ( don't know which application might use this concept ) -Somesh * Please dont take the print out of this e-mail unless its absolutely necessary * -Original Message- From: Alex Balashov [mailto:abalas...@evaristesys.com] Sent: Monday, January 12, 2009 4:42 PM To: Somesh S. Shanbhag Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SDP payload in 487. What, do you suppose, is the motive? This is coming from a Squire signaling agent. Somesh S. Shanbhag wrote: > RFC wont restrict a user from not sending SDP in 487 and even if he does > that it wont be useful. Yes, you can send SDP in 487. > > -Somesh > > -Original Message- > From: Alex Balashov [mailto:abalas...@evaristesys.com] > Sent: Monday, January 12, 2009 4:37 PM > To: Somesh S. Shanbhag > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SDP payload in 487. > > I understand that it doesn't really serve any purpose. > > Should it be there at all? > > Somesh S. Shanbhag wrote: > >> 487 Request Terminated must be for INVITE transaction. >> and since the transaction was not successful, even if the SDP is > present >> we need to ignore it. >> >> -Somesh >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of >> Alex Balashov >> Sent: Monday, January 12, 2009 4:30 PM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: [Sip-implementors] SDP payload in 487. >> >> I am getting an SDP payload in a 487 Request Terminated message in >> response to a CANCEL (first a 200 OK, then a 487). >> >> Is this allowed? >> > > -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP payload in 487.
RFC wont restrict a user from not sending SDP in 487 and even if he does that it wont be useful. Yes, you can send SDP in 487. -Somesh -Original Message- From: Alex Balashov [mailto:abalas...@evaristesys.com] Sent: Monday, January 12, 2009 4:37 PM To: Somesh S. Shanbhag Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SDP payload in 487. I understand that it doesn't really serve any purpose. Should it be there at all? Somesh S. Shanbhag wrote: > 487 Request Terminated must be for INVITE transaction. > and since the transaction was not successful, even if the SDP is present > we need to ignore it. > > -Somesh > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Alex Balashov > Sent: Monday, January 12, 2009 4:30 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SDP payload in 487. > > I am getting an SDP payload in a 487 Request Terminated message in > response to a CANCEL (first a 200 OK, then a 487). > > Is this allowed? > -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP payload in 487.
487 Request Terminated must be for INVITE transaction. and since the transaction was not successful, even if the SDP is present we need to ignore it. -Somesh -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Alex Balashov Sent: Monday, January 12, 2009 4:30 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SDP payload in 487. I am getting an SDP payload in a 487 Request Terminated message in response to a CANCEL (first a 200 OK, then a 487). Is this allowed? -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Use of REGISTER with Contact different than theUA's contact
Its useful in third party registrations. # TCP from 10.10.0.222:12345 to registrar REGISTER sip:registrar SIP/2.0 From: Contact: 10.10.0.111:5060;transport=UDP To: In the above example, Observe To: is alice AOR. -Somesh -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Iñaki Baz Castillo Sent: Fri 12/12/2008 2:55 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Use of REGISTER with Contact different than theUA's contact Hi, I think I already was replied to a similar question but unfortunatelly I don't find it. The question is: when/where is useful sending a REGISTER with a Contact different than the UA's contact? For example: Phone1: - AoR: al...@domain.org - Listen: 10.10.0.111:5060;transport=UDP Phone2: - AoR: b...@domain.org - Listen: 10.10.0.222:5060;transport=TCP Now Phone2 sends a REGISTER like: # TCP from 10.10.0.222:12345 to registrar REGISTER sip:registrar SIP/2.0 From: Contact: 10.10.0.111:5060;transport=UDP I think this is useful in IMS, am I right? what for exactly? any other case? Thanks a lot. -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Calling Self
I think it should return 486 Busy, as we observe that same in PSTN phones Somesh Srinivas Shanbhag M G L B a n g a l o r e -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of tamal.bis...@wipro.com Sent: Fri 12/12/2008 11:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Calling Self What is the expected behaviour is a user calls himself ? Should the called handle the Invite and call should get established Or cancel should be send or else some error response can be set. Thanks & Regards Tamal Tanu Biswas Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP stack
There are some SIP stacks available open source. You can take them as reference. reSIProcate VOVIDA oSIP - Somesh -Original Message- From: [EMAIL PROTECTED] on behalf of cool goose Sent: Tue 12/2/2008 12:02 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SIP stack Hi Everyone, I am new to the SIP and just started reading RFC 3261. I am planning to write my own SIP stack with minimum functionality (setting up a basic call and tear down). Can someone point me to the right resources that can assist me in this? Also, can someone explain what I needs to be considered in the component architecture for SIP stack? Thank You, CoolGoose. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query regarding 'To' tag in REGISTER request
I think that should be fine. Because REGISTER wont establish the dialog and rather establish the binding which is To header value and Contacts Somesh S Shanbhag Mascon Global Limited Bangalore, India -Original Message- From: [EMAIL PROTECTED] on behalf of Tarun2 Gupta Sent: Fri 11/21/2008 10:36 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query regarding 'To' tag in REGISTER request Hi All Consider the following scenario: REGISTER-->with Expires 3600 < 200 ok with a 'To' tag and Expires 3600 Successful registration done. .. .. REGISTER-> with Expires 0 and Contact * Is it ok for this de-REGISTER request not to have the 'To' tag as received in the 200 ok response? Whats the role of Tags in case of a REGISTER request? Thanks in advance. Tarun Gupta "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] query in Magic cookie
The magic cookie is an indication of the UA being RFC3261 compliant. So, if its missing, the UA is not RFC3261 compliant. I would say you would still accept the call and process the call for backward compatibility for RFC2543 compliance. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Sudhir Kumar Reddy Sent: Wed 11/19/2008 5:33 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] query in Magic cookie Hi All, I would like to know if magic cookie is missing in VIA header. what would be the behavior of B2BUA? Should it process request / discard packet? Thanks in advance Sudhir Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Bridged Line Appearance.
Comments Inline with [SSS] Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Suresh Arunachalam Sent: Mon 11/10/2008 5:03 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Bridged Line Appearance. Hello All, I am in the process of implementing Bridged line appearance with Subscribe/ Notify mechanism and have some doubts on error cases for subscribe / Notify other than 481 which clearly gives a hint "call leg does not exist". My doubts are How a server would handle if a 408 / 5xx response error being received. Do we need to remove the subscription?. [SSS] Do you mean to say 5XX for NOTIFY? Also is it acceptable to send ACK for NICT in case of these errors though it not mentioned in RFC 3261. [SSS] ACK is only for INVITE and is not acceptable for NICT or NIST. Thanks in advance -- A.Suresh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Same CSeq value in subsequent request in Dialog
Hi, You can generate "500 Internal Server Error" for BYE request. Regds Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Vicky Sent: Mon 11/10/2008 2:06 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Same CSeq value in subsequent request in Dialog Hi, What is UAS supposed to do if the CSeq number for the subsequent in a dialog request is equal to previous CSeq? As in RFC 3261 section 12.2.2 only talks about less than or greater than values. UA UA <- - - - - - - - - - - - - - - - - - - - - - -- - -Invite/SDP 100--- - - - - -- - - - - - - -- - - - - - - --> 180--- - - - - -- - - - - - - -- - - - - - - --> 200/SDP-- - - - - -- - - - - - - -- - - - - - - --> < - - - - - - -- - - - - - - - - - - - - - - - - - -ACK <- - - - - - - - - - - - - - - - - - - - - - -- - -Invite 100--- - - - - -- - - - - - - -- - - - - - - --> 200--- - - - - -- - - - - - - -- - - - - - - --> < - - - - - - -- - - - - - - - - - - - - - - - - - -ACK < - - - - - - -- - - - - - - - - - - - - - - - - - -BYE X--- - - - - - - - - - - - - - - - - - - - - - - - -> *Regards, -Vicky* ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP and BFCP
Have been working on SBC, but haven't seen the RFC 4145 usage so far. Regards, Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Raghavendra Kamath Sent: Wed 11/5/2008 3:06 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SIP and BFCP Hi All, We are in the process of implementing BFCP for the purpose of floor control in video presentation. The draft that defines this is RFC 4582. But I see that this spec requires exchange of BFCP protocol messages over TCP. I would like to know from anyone about what is the feasibility of this mechanism succeeding with proxies. If the proxy acts as a media gateway (B2BUA), what would it behave like? Since this is modeled after RFC 4145(TCP-Based Media Transport in the Session Description Protocol), what has been the success of endpoints to get this kind of a SDP across the standard proxies. This(RFC 4582) seems to be the only solution for floor control but I am afraid it might be completely un-interoperable. At least if anyone can comment about their success rate with RFC 4145, I'd be very happy. -Thanks Kamath, LifeSize Communications ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] rtpmap:18 G729a/8000 ?
I think you need to represent in two lines a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Mon 11/3/2008 6:08 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] rtpmap:18 G729a/8000 ? Hi, Please let me know if "rtpmap:18 G729a/8000" is a wrong format. I guess RFC3551 says it should work (page 19, as pasted below) and I am not able to find anything so specific in RFC3550. 4.5.6 G729 G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 8 kbit/s using conjugate structure-algebraic code excited linear prediction (CS-ACELP)". A reduced-complexity version of the G.729 algorithm is specified in Annex A to Rec. G.729. The speech coding algorithms in the main body of G.729 and in G.729 Annex A are fully interoperable with each other, so there is no need to further distinguish between them. An implementation that signals or accepts use of G729 payload format may implement either G.729 or G.729A unless restricted by additional signaling specified elsewhere related specifically to the encoding rather than the payload format. The G.729 and G.729 Annex A codecs were optimized to represent speech with high quality, where G.729 Annex A trades some speech quality for an approximate 50% complexity reduction [10]. See the next Section (4.5.7) for other data rates added in later G.729 Annexes. For all data rates, the sampling frequency (and RTP timestamp clock rate) is 8,000 Hz. -- Thanks & Regards Viresh Gupta Manager - International Network Planning Enterprise Services, Bharti Airtel Limited, 234, Okhla Industrial Area, Phase- III, New Delhi - 110020, India D (91) 1141711283 M (91) 9871008236 E [EMAIL PROTECTED] Airtel for Business On your side. By your side. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure,dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. The recipient acknowledges that Bharti Airtel Limited or its subsidiaries and associated companies(collectively "Bharti Airtel Limited"),are unable to exercise control or ensure or guarantee the integrity of/overthe contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of Bharti Airtel Limited. Before opening any attachments please check them for viruses and defects. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] sdp with missing m line
Inline with [SSS] Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of karthik karthik Sent: Fri 10/31/2008 11:05 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] sdp with missing m line Hello All, Please let me know the behavior for the below cases. I believe 'm=' line is not mandatory according to rfc 4566 Still It was decided to release the session in our application. case1: Invite is received with SDP, and has no 'm=' line. In case we need to reject such an Invite, what is the most suitable response code? Could we use 415 unsupported media type.? [SSS] I think the response code 415 is used when UAS doesn't understand the SDP itself. In this case you can reject with 403 Forbidden. case2: 18x/200 recieved with SDP, and has no 'm=' line. for 18x, send CANCEL for 200, send ACK and BYE. Is this OK? [SSS] If 18x has no m= line, I think we can discard and remain silent unless UAC issues CANCEL because chances are there that 200 might have m= line and call may be successful. ( Best Effort Service ) If 200 has no m= line then I think its okay to send BYE as the Call is not meaningful w.r.t. Voice call. If its meaningful in some other service we may not tear it down. Thanks Karthik ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP media change - Is the precedence forc=0.0.0.0 or a= attribute?
Hi, I think the first preference must be a=sendonly followed by c=0.0.0.0 which is just the backward compatibility. This will also ensure the cases where in the given SDP, some m lines are on hold while some are not. Regards, Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Subbu Rajendran Sent: Fri 10/24/2008 3:40 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SIP media change - Is the precedence forc=0.0.0.0 or a= attribute? Hi, SIP RFC 2543 uses c=0.0.0.0 method to put a call on hold. RFC 3264 has introduced a=sendonly/recvonly/inactive/sendrecv attributes that can be used put media to one way, hold and 2-way. However what should be the precedence to be followed? Consider the case below A Re-INVITE with SDP v=0 o=user1 53655765 2353687637 IN IP4 192.168.1.100 s=- c=IN IP4 0.0.0.0 t=0 0 m=audio 6001 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly How should the SIP endpoint receiving this Re-INVITE interpret the SDP, w.r.t the flow of media. Which method should be given preference. Any help in this context is very much appreciated. Thanks & Regards, Subbu ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] In dialog error response
Comments inline with [SSS] Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Bartosz Baranowski Sent: Thu 9/25/2008 7:08 PM To: sip-implementors@lists.cs.columbia.edu; M. Ranganathan Subject: [Sip-implementors] In dialog error response Hi Im facing some doubts about sip implementation we use. Didnt find that on mailing list and google so... According to rfc non final 2xx response termiantes dialog if its in early state. What is desired behaviour for in dialog response to request? For instance: UAC UAS | - INVITE -> | | < 100 --- | | < 180 --- | | < 200 --- | | - ACK > | | - INFO ---> | | < 500 | After sending 500 UAS should not receive DialogTerminated event, should it? This is what is in rfc, maybe I missed some vital part: [SSS] The 500 Error is for INFO and the Dialog doesn't terminate. Only that the INFO(example: DTMF) didn't serve the purpose. To terminate the established dialog, send BYE Even if the mid-dialog INVITE fails, it resumes to earlier what has been exchanged. [/SSS] A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates. 13.2.2.3 4xx, 5xx and 6xx Responses A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored. All early dialogs are considered terminated upon reception of the non-2xx final response. -- Bartosz Baranowski JBoss R & D == Word of criticism meant to improve is always step forward. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Updation of remote information on receipt ofACK
Prateep: Actually what Rockson told is correct RFC5057 sec5.4 Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER Thanks, Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Prateep K. Sent: Thu 9/25/2008 6:13 PM To: Navneet Gupta; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Updation of remote information on receipt ofACK Hi, Please see comments below >> Thanks, K.Prateep -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Navneet Gupta Sent: Thursday, September 25, 2008 2:08 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Updation of remote information on recipt of ACK Hi I have the following queries regarding remote updation due to ACK request. 1. Scenario is a normal incoming Call. INVITE - 200 OK - ACK. If the contact adress recieved in ACK is different from the one recieved in INVITE, should we update the contact address or the peer? >> Yes, since it's a successful call latest contact in ACK can be considered 2. After a successful call is established and the dialog is updated through successful Re-INVITE, should the contact address of the peer be updated with ACK? >> Yes, since Mid-dialog request is a successful call latest contact in ACK will be considered 3. After a successful call is established, peer sends Re-INVITE which is rejected by us and in the ACK, peer sends new contact address. Should the contact address of the peer be updated with this ACK? >> No, since Mid-dialog request is an unsuccessful call. Regards Navneet *DISCLAIMER* This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately and delete the message. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail
Re: [Sip-implementors] Max Length of "Sip Display Name" field in Fromheader
No Limit as long as it is quoted string Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Hari Kumar Sent: Tue 9/23/2008 3:38 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Max Length of "Sip Display Name" field in Fromheader Hi All, Can you please tell me, where we can get the information related to "Max Length of "Sip Display Name" field in From header". I would also like to know, which are the characters, that are allowed in "Sip Display Name" filed. Regards Hari DISCLAIMER: This message is proprietary to D-Link (India) Limited and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. D-Link (India) Limited accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Broadsoft FAX problem
Rohit, You may be right, may be driven by configuration or may be because the client didn't indicate the T38 capability its switching automatically to G711 Mode. Somesh S Shanbhag M G L Bangalore -Original Message- From: Rohit Aggarwal [mailto:[EMAIL PROTECTED] Sent: Fri 9/19/2008 2:51 PM To: Somesh S. Shanbhag; Neranza Bundova; sip-implementors@lists.cs.columbia.edu Subject: RE: Broadsoft FAX problem Hi If I understand it correctly, Somesh is suggesting addition of T38 media stream in offer from the endpoint whereas Neranza's query is how to make Broadsoft initiate T.38 fax instead of Pass-Through on tone detection? I think Neranza wants that Broadsoft should add T38 stream in the Re-INVITE, probably some server configuration?? Please correct me if my interpretation of the original query is wrong. Regards Rohit Aggarwal Aricent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Somesh S. Shanbhag Sent: Friday, September 19, 2008 2:42 PM To: Neranza Bundova; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Broadsoft FAX problem I think you will have to put something like this in SDP m=image 1 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:300 a=T38FaxUdpEC:t38UDPRedundancy Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Neranza Bundova Sent: Fri 9/19/2008 12:56 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Broadsoft FAX problem Hello All, I have a problem with sending a T38 FAX over a Broadsoft server. I am sending to a PSTN FAX so the Broadsoft server is terminating SIP point and it should send me REINVITE for T38 but it does not. It is just accepting the FAX transmission over G711. My question is there some specific advertisement(media attribute or media description) which I should add in my initial INVITE request to the Broadsoft server to make it understand that I support T38? I saw also something called "Broadsoft FAX Messaging" but did not find any description. Thanks ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Ma
Re: [Sip-implementors] Broadsoft FAX problem
I think you will have to put something like this in SDP m=image 1 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:300 a=T38FaxUdpEC:t38UDPRedundancy Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Neranza Bundova Sent: Fri 9/19/2008 12:56 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Broadsoft FAX problem Hello All, I have a problem with sending a T38 FAX over a Broadsoft server. I am sending to a PSTN FAX so the Broadsoft server is terminating SIP point and it should send me REINVITE for T38 but it does not. It is just accepting the FAX transmission over G711. My question is there some specific advertisement(media attribute or media description) which I should add in my initial INVITE request to the Broadsoft server to make it understand that I support T38? I saw also something called "Broadsoft FAX Messaging" but did not find any description. Thanks ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] reject sdp offer with multiple media lines
Can you please provide sample SDP of both sides? Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Neranza Bundova Sent: Thu 9/18/2008 4:48 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] reject sdp offer with multiple media lines Hi All, I am not sure how a user agent should reject an offer when: UA "A" and UA "B" are in call and they have negotiated an audio session. UA "A" sends re-INVITE request to "B" with SDP that rejects the media by setting the port number to 0. UA "A" adds another media to the SDP offer that "B" understand but can not accept. 1. When UA "A" should release the resource used for the media stream? a. when an sdp answer from "B" is received b. when "A" sends the sdp offer. 2. What B will do in this situation? a. Will send sdp answer with all media ports set to 0? Should B close the dialog b. Will send 488 response i. A will close the dialog ii. A and B will continue the dialog and will use already negotiated media stream ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can multiple Via header be present in initialINVITE request ?
Actually the answer is No. When UAC sends the request, it can insert only its Via which is one Via header. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Sourav Dhar Chaudhuri Sent: Thu 9/18/2008 12:34 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Can multiple Via header be present in initialINVITE request ? Hi, Can multiple Via header be present in initial INVITE request ? I mean to say when first time INVITE request is generated from UAC without traversing any PROXY can contain multiple Via header ? If yes then what is the need of having multiple Via header in initial INVITE request? Thanks Sourav Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] intrusion in INFO
Actually INFO is usually sent out as part of MID_DIALOG. But when the new call comes to A, the IMSServer can send 180 as follows. SIP/2.0 180 --Waiting for Call-- and if A disconnects, it can automatically connect. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of karthik karthik Sent: Wed 9/17/2008 1:13 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] intrusion in INFO Hello, How can we play tone(intrusion) in active dialog? For instance if A and B exist in active dialog. IMS Application server serving A received a new call to A and wishes to inform a waiting tone to A, in the A-B active dialog. Is this possible with method INFO? If yes, what is the content-type and subtype? Thanks Karthik Prabhu ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Calculating cnonce-value
cnonce is arbitrary quoted string. We used to generate using the Hash(Timestamp+message+constant) Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Stephen Paterson Sent: Tue 9/16/2008 5:36 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Calculating cnonce-value Hi all, Quick question. Are there any recommended/suggested ways of generating a cnonce for use with a RFC 2617 compliant UAC or is it just an arbitrary quoted string? I've found plenty of info on nonce but not so much on cnonce and it seems I can just pick any old string. Any references much appreciated. Cheers Steve Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) P Please consider the environment and don't print this e-mail unless you really need to ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] A question about AKAv1-MD5 authentication
Also, look at RFC 4187, which describes the AKA exchange in detail while the TS34.229 gives the exact algorithm to compute the keys as Prakash told. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Prakash Mariasusai Sent: Mon 9/15/2008 5:41 PM To: Navneet Gupta; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] A question about AKAv1-MD5 authentication Hi Navneet, Please check specs - TS34.229, Section 8 and 9, for authentication scenarios and TS 33.203 for the calculation of Auth. Vectors. RFC 3310 mentions only about how the SIP headers should look like for the above auth mechanism and provides the basic scenarios and not about how to calculate the auth vectors and so on. Thanks, Prakash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Navneet Gupta Sent: Monday, September 15, 2008 5:27 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] A question about AKAv1-MD5 authentication Hi I'm trying to implement support for AKAv1-MD5 authentication in a SIP UA. I can't find any valid examples of authentication scenarios using AKAv1-MD5. I read a post on the group which said that the examples given in RFC 3310 - "HTTP digest authentication using AKA" contain invalid nonce values. Please help! Regards Navneet *DISCLAIMER* This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately and delete the message. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Fetching Bindings
Also to substantiate that Contact header is optional for 200 OK for REGISTER, here is one more context in RFC. See Table 2: Summary of header fields, A--O of RFC 3261, just after section 20.1. Header field where proxy ACK BYE CAN INV OPT REG Contact2xx - - - m o o This says that Contcat in 2XX for INVITE is mandatory while for REGISTER is optional. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Jesus Rodriguez Sent: Thu 9/11/2008 3:28 PM To: Iñaki Baz Castillo Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Fetching Bindings Hello, > El Jueves, 11 de Septiembre de 2008, Victor Pascual Ávila escribió: >> Scenario: a SIP UA is not registered and it sends a REGISTER request >> without Contact header. >> >> A success response to any REGISTER request contains the complete list >> of existing bindings, regardless of whether the request contained a >> Contact header field. >> >> Contact cannot be empty: >> Contact = ( "Contact" / "m" ) HCOLON >> ( STAR / (contact-param *(COMMA contact-param))) >> contact-param = (name-addr / addr-spec) *( SEMI contact-params) >> >> >> RFC3261, Section 10.3- Step 8 says: >> >> "The registrar returns a 200 (OK) response. The response MUST >> contain >> Contact header field values enumerating all current bindings." >> >> It should say: >> >> "The registrar returns a 200 (OK) response. If there exist any >> bindings for that AOR, the response MUST contain Contact header field >> values enumerating all current bindings." >> >> Am I right? > > > I 100% agree. This seems a bug since a Contact cannont be empty (BNF > syntax) > but there is a "MUST contain Contact". I also agree with Victor. If no bindings exist, the 200OK should not have a Contact header. Saludos JesusR. Jesus Rodriguez VozTelecom Sistemas, S.L. [EMAIL PROTECTED] http://www.voztele.com Tel. 902360305 - ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Fetching Bindings
Hi, The "current bindings" in RFC section quoted, does mean "If Bindings for this AOR exists". I mean, if bindings for the specified AOR exists, then its termed as "current" bindings. The RFC text is correct. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Victor Pascual Ávila Sent: Thu 9/11/2008 2:41 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Fetching Bindings Scenario: a SIP UA is not registered and it sends a REGISTER request without Contact header. A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. Contact cannot be empty: Contact = ( "Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *( SEMI contact-params) RFC3261, Section 10.3- Step 8 says: "The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings." It should say: "The registrar returns a 200 (OK) response. If there exist any bindings for that AOR, the response MUST contain Contact header field values enumerating all current bindings." Am I right? Cheers, -- Victor Pascual Ávila ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] More on when to open rtp listen port
Hi, Once you send the offer ( either in INVITE or in 200 OK delayed media ), its implicit the UA must be ready to listen on the specified ports in the offer. So, UA should open the ports immediately after sending 200 OK offer. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Elison Niven Sent: Tue 9/9/2008 4:07 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] More on when to open rtp listen port Hi, Now if I receive an INVITE without an SDP, I send the offer in the 200 OK. So should I open the listen port before or after receiving the ACK? If I do so after receiving the ACK, there are chances that a few ICMP packets may be sent back to the first few received RTP. So should I open the rtp listen port on sending 200 OK or on receiving the ACK in this case? Best Regards, Elison ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] When to open RTP listen port
Thats normal! The moment you send the 200 OK you must be prepared to receive the media. Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Anuradha Gupta Sent: Mon 9/8/2008 10:05 AM To: Elison Niven; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] When to open RTP listen port The behavior of sending RTP data on receipt of 200 OK response is normal. Once the final answer is sent, the offer-answer media negotiation is complete. Therefore RTP listening port can be opened just after sending final success response (200 OK) and on the other side RTP data can be sent right after receiving the final success response. Regards Anuradha Gupta Technical Leader(Aricent) Ext : 5119 Mobile : 9811814731 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elison Niven Sent: Saturday, September 06, 2008 3:34 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] When to open RTP listen port Hi, I am facing a problem that when I send a 200 OK, a remote UA immediately starts sending RTP after sending the ACK before my device has yet managed to opened that port. The result is that my device sends an ICMP for the first two received RTP packets. Is this behavior normal or should I not wait for the ACK but open the RTP listen port as soon as I send the 200 OK? Best Regards, Elison ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility forloss or damage arising from the use of the information transmitted by this email including damage from virus." ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query on REGISTER /INVITE request
Sudhir: You are right. 400 Bad Request needs to be generated. Refer section 21.4.1 of RFC 3261 Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of Sudhir Kumar Reddy Sent: Fri 9/5/2008 10:41 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query on REGISTER /INVITE request Hi Folks!!! I would like to know if any mandatory header is missing in REGISTER / INVITE request, what would be the B2BUa behaviour? Should it not send 400 bad request? Is there any section talking about on same? Sample REGISTER: Message1: In this case CSEQ method is not correct, what would be Response for this request REGISTER sip:sample.com SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sip:[EMAIL PROTECTED] ;tag=[call_number] To: sip:[EMAIL PROTECTED] Call-ID: 1233445 CSeq: [cseq] TEST Contact: Content-Length: 0 Expires: 3000 Message2: In this case Call Id missing what would be Response for this request REGISTER sip:sample.com SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sip:[EMAIL PROTECTED] ;tag=[call_number] To: sip:[EMAIL PROTECTED] CSeq: [cseq] TEST Contact: Content-Length: 0 Expires: 3000 Apologies if this has already been discussed. Any Response is highly appreciated Regards, Sudhir Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Change of Allow header content within a dialog
I think you are right! Though the RFC doesn't specify, semantically it wont make sense to change it. Somesh S Shanbhag Mascon Global Limited -Original Message- From: [EMAIL PROTECTED] on behalf of Jagan Mohan Sent: Fri 8/22/2008 10:33 AM To: SIP Implementors Subject: [Sip-implementors] Change of Allow header content within a dialog Hi All, I would like to know whether the content (SIP Methods supported) of Allow header can change within a dialog. For example, can 100 Trying message have "Allow: INVITE ACK BYE CANCEL OPTIONS UPDATE" and 180 Ringing message have "Allow: INVITE ACK BYE CANCEL OPTIONS" in the same dialog? I don't see any specific mention of this in RFC 3261. Logically, I feel the behavior of UA sending the above messages is not correct. Thanks, Jagan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Digest Authentication in multihoming application
I think A has to include both the Authorization Headers. Depending upon the "realm" B2BUA / B will select the relevant Authorization Headers. Somesh S Shanbhag Mascon Global Limited -Original Message- From: [EMAIL PROTECTED] on behalf of Vivek Batra Sent: Tue 8/19/2008 5:42 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Digest Authentication in multihoming application Hi, I have query regarding challenge response mechanism (digest authentication, MD5) in SIP as follows: A and B are SIP clients registered with B2BUA. A calls B and sends INVITE to B2BUA. B2BUA challenges INVITE with response 407 Auth. A again sends the INVITE with authentication header (say H1) and required credentials to B2BUA. B2BUA sends this INVITE to B. B has a capability to challenge the INVITE (like Linksys 3102 etc). So, B sends the response 407 Auth. to B2BUA. B2BUA passes this response viz 407 to A. A again generates the INVITE with authentication header (say H2) and sends it to B2BUA. Now my question is 'What should be the implementation in A regarding Authentication Header. Should A includes only authentication header H2 in INVITE or both H1 and H2?' In both the cases whether A includes H1 or H1 and H2 as Authentication Header in INVITE, what should be the implementation in B2BUA when received this INVITE from A since B2BUA has already been authenticate the caller viz A?? Is any RFC describing this scenario? Thanks and Kind Regards, Vivek ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Who must add the "To tag" to a response
"to-Tag" is TU specific and must be added by the concerned TU. For Example, if server is behaving as Proxy, the ProxyCore would add "to-Tag" and pass the response to the transaction. Since, adding "to-Tag" is common across Proxy, Registrar or B2BUA, it can also be added as part of common processing, which is again TU. Cheers! Somesh -Original Message- From: [EMAIL PROTECTED] on behalf of Iñaki Baz Castillo Sent: Thu 8/14/2008 6:27 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Who must add the "To tag" to a response Hi, imagine a non specific SIP stack that could have a proxy core, UAS core, B2BUA, registrar, being a stateless proxy... I'm getting a bit crazy to determine which layer must add the "To tag" to the response if it has not, and also how to use the same "To tag" in more responses for the same transaction. Also, it's required to add a "To tag" in a response sent stateless (a 401 for auth for example). Any suggestion please? Thanks. -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is preferible 408 instead of 480 when calleedoesn't answer?
I think both are fine because both would tear-down the transaction and would mean almost the same thing. But still 408 would have been more appropriate as its from Gateway, rather than 480 which is more likely to be client driven. And also in 480, we can get Re-Try after header, the time after which I can attempt calling again! Its more implementation dependent. Cheers! Somesh -Original Message- From: [EMAIL PROTECTED] on behalf of Iñaki Baz Castillo Sent: Wed 8/13/2008 7:39 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Is preferible 408 instead of 480 when calleedoesn't answer? Hi, when calling to two SIP/PSTN gateways, if the callee doesn't reply in XX seconds then the gateway sends me a "480 User Unavailable". Well, I think is much better using "408 Timeout", isn't it? Thanks. -- Iñaki Baz Castillo [EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] few queries regarding SDP implementation for multiple bit rates for g.722 codec
(Query 1) I think you can specify multiple a= lines in SDP m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/48000 a=rtpmap:9 G722/56000 a=rtpmap:9 G722/64000 (Query 2) m=audio 9292 RTP/AVP 9 0 a=rtpmap:9 G722/64000 a=rtpmap:0 PCMU/8000 m=audio 9296 RTP/AVP 9 18 a=rtpmap:9 G722/56000 a=rtpmap:18 G729/8000 m=audio 9298 RTP/AVP 9 a=rtpmap:9 G722/48000 (Query 3) Honestly dont know which one is better in network. Somesh lalit kumar <[EMAIL PROTECTED]> wrote: Help needed regarding G.722 codec negotiation. I have few queries regarding SDP implementation for multiple bit rates for g.722 codec. As we know that g.722 supports 48,56 and 64 kbps. Query-1: à I want to negotiate g.722 codec with multiple bitrates 64 56,and 48. Then what would be SDP attributes value in Sip invite. Query-2à if I have following codec order for negotiation, then what would be the SDP for Sip Invite? G.722 at 64 kbps PCMU G.722 at 56 kbps G.729 G.722 at 48 Kbps Query-3 à On network what flavor of G.722 codec is better at bit rates (64,56 or 48 kbps)? Please help me out, Thanks in advance. Thanks, Lalit -- Thanks & Regards Lalit Kumar ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Can you also attach the original INVITE call flow along with re-INVITE? That can help to compare the SDP versions, CSeq etc. Also, if everything turns out to be OK, then there may be some policy (private) based on which it might be rejecting! Somesh [EMAIL PROTECTED] wrote: Hi, I'm havin a problem sending a re-invite message to change the current SDP-Session. The Reinvite itsself causes the receiver to generate an OK message with its SDP. But after receiving the following Request ACK it just generates a BYE and ends. Does anyone see the problem? Is the Reinvite correct? Are the CSeqs ok? many thanks in advance!! Andreas packet capture: [RE-INVITE:] Session Initiation Protocol Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Message Header Record-Route: Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.0 Via: SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4bKfzzdcjdi Max-Forwards: 69 To: ;tag=dyyrq From: ;tag=dochj Call-ID: [EMAIL PROTECTED] CSeq: 996 INVITE Sequence Number: 996 Method: INVITE Contact: Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO Supported: replaces,norefersub,100rel User-Agent: Twinkle/1.0 Content-Length: 305 P-hint: usrloc applied Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 100 295838384 725581350 IN IP4 134.2.172.238 Owner Username: 100 Session ID: 295838384 Session Version: 725581350 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 134.2.172.238 Session Name (s): - Connection Information (c): IN IP4 134.2.172.238 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 134.2.172.238 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8000 RTP/AVP 3 98 97 8 0 101 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute (a): * [OK, WITH SESSION DESCRIPTION] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.0,SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4bKfzzdcjdi To: ;tag=dyyrq From: ;tag=dochj Call-ID: [EMAIL PROTECTED] CSeq: 996 INVITE Sequence Number: 996 Method: INVITE Contact: Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO Server: Twinkle/1.0 Supported: replaces,norefersub Content-Length: 304 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 101 1577192660 821447339 IN IP4 134.2.173.47 Owner Username: 101 Session ID: 1577192660 Session Version: 821447339 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 134.2.173.47 Session Name (s): - Connection Information (c): IN IP4 134.2.173.47 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 134.2.173.47 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8002 RTP/AVP 98 97 8 0 3 101 Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute (a): ptime:20 * [ACK]: Session Initiation Protocol Request-Line: ACK sip:[EMAIL PROTECTED] SIP/2.0 Message Header Record-Route: Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.2 Via: SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4b
Re: [Sip-implementors] 480 or 503
If the endpoint is UA, 480 would be a appropriate and if it is server 503 would be appropriate. Somesh "Kang, Hai Tao (Hai Tao)" <[EMAIL PROTECTED]> wrote: Hello, In my project, a sip termination may be under certain maintenance testing. In the process of termination testing, if an incoming call is received, which response code is more appropriate, 480 or 503? Since according to 3261, they both seem to be ok. 480: The callee's end system was contacted successfully but the callee is currently unavailable. (for example,logged in but in a state that precludes communication with the callee). 503: The server is temporarily unable to process the request due to a temporary maintenance of the server. Thanks in advance. Kang Haitao ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Got a little couch potato? Check out fun summer activities for kids. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can NOTIFY with state "pending" follow NOTIFY with state "active"??
Sumit: Actually I am not getting when such scenario will occur. If the Notifier has sent "active" that means it has found matching policy for the resource. Subscriber would have already created the dialog and if at all Notify wants to move the subscription to Pending .. it would better terminate and let the subscriber re-subscribe again. Somesh Sumit Chopra <[EMAIL PROTECTED]> wrote: Hi All My question is -- If a subscription is in "active " state, can it be moved to "pending" state i.e can a UA generate NOTIFY request with state "pending" if it has previously generated the NOTIFY request with state "active" If so, what are the different scenarios under which this is possible? thanks and Regards Sumit *DISCLAIMER* This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately and delete the message. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Non-subscribe mechanism for creating subscription
Anshuman: I think the non-Subscription mechanisms should create a dialog or context within which NOTIFYications are issued! Somesh "Anshuman S. Rawat" <[EMAIL PROTECTED]> wrote: Hi All, Sec 3.2 in RFC 3265 states - " If any non-SUBSCRIBE mechanisms are defined to create subscriptions, it is the responsibility of the parties defining those mechanisms to ensure that correlation of a NOTIFY message to the corresponding subscription is possible." My question is - what happens to dialog creation? If I create a subscription (by prog. means) using non-subscribe mechanism, will the NOTIFY create a dialog? Or should the non-subscribe mechanism being used also be used to create an implicit dialog? Regards, Anshuman ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query in DisplayName?
Sudhir, I dont think there is any restrictions on DisplayName length. Each header should not exceed 998 characters and 78 characters per line (RFC 2822) Somesh sudhir kumar <[EMAIL PROTECTED]> wrote: Hi All, What is the max length of DisplayName can be a accommodated in To/From Headers? Thanks, Sudhir - Once upon a time there was 1 GB storage in your inbox. Click here for happy ending. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] No NOTIFY for SUBSCRIBE
Hi, I think we can send the periodic SUBSCRIBE requests or UPDATE requests because Subscriptions establish dialogs and try to check the health of the subscription / server. Somesh Shankarachar Subramanya-a22587 <[EMAIL PROTECTED]> wrote: Hi, If the server crashes after sending 200OK for SUBSCRIBE and if we don't get NOTIFY at all, then subscriber will in the subscribed state for long time, if the subscription intervel is too long (default is 2 hrs), is there any way to figure it out...? Regards, Subramanya. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] ACK - separate transaction
Hema: I think ACK for 2XX response may participate in SDP negotiations (Delayed Media) and therefore UA (TU) has to initiate the same and a separate transaction. But ACK for non-2XX (3XX-6XX failures) it may not be applicable because its failure and therefore transaction layer takes care of it! Somesh Hema R <[EMAIL PROTECTED]> wrote: Hi, What is the reason for including ACK in an INVITE transaction for a non-2xx response and making it a separate transaction for a 2xx response? Is there any specific reason from the design perspective? Thanks, Hema. Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/Disclaimer.html internally within Tech Mahindra. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Ack is lost
I think ACK is not mandatory in some of 2543 UA's. and if everything is OK, I mean codec negotiations etc Gateway should allow the media pass through -Somesh varun <[EMAIL PROTECTED]> wrote: Hi, Another media issue: user A->GateWay->user B --->Invite < 200 OK Ack is lost( no Ack) Here the Gateway does not receive the ACK but user A starts transmitting the media so what should the gateway do with the media?Play the media or ignore it till we get an ACK. Thanks varun Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
