Re: [Sip-implementors] What is the rule for retransmitting the SIP packet
Are you asking how TCP handles retransmission internally, or are you asking about retransmission intervals in SIP for messages sent over “unreliable transport”? If the latter, every message type (it might be more accurate to say “message genre”) has different retransmission limits, and they are all regulated by Timer T1/T2/T4 and Timer A-K. See RFC 3261 page 264, “A Table of Timer Values”. > On Apr 10, 2023, at 2:06 PM, Arun T wrote: > > Thanks, but what is the interval and how many times? Any spec. Or RFC ? > Please suggest > > On Mon, 10 Apr 2023 at 11:35 PM, Ranjit Avasarala > wrote: > >> TCP takes care of re-transmissions. >> >> On Mon, Apr 10, 2023 at 11:25 AM Arun T wrote: >> >>> Thanks RFC talks about the non-reliable transport (UDP) what about >>> reliable >>> transport (TCP). Don’t UE/NW retransmit? >>> >>> On Mon, 10 Apr 2023 at 7:12 PM, Roman Shpount wrote: >>> >>>> Please take a look at hhttps:// >>> www.rfc-editor.org/rfc/rfc3261#section-17 >>>> _ >>>> >>>> Roman Shpount >>>> >>>> >>>> On Mon, Apr 10, 2023 at 9:20 AM Arun T wrote: >>>> >>>>> Hi All, >>>>> >>>>> Can any one share the spec./RFC which has information that SIP messages >>>>> can >>>>> be re-transmitted if no response is received? >>>>> >>>>> What is the interval for retransmitting ? And how many retransmissions >>> are >>>>> permitted or allowed ? Does it depend on any timer ? >>>>> >>>>> -- >>>>> >>>>> With Regards >>>>> >>>>> Arun A. Tagare >>>>> +91 9449 029729 >>>>> ___ >>>>> Sip-implementors mailing list >>>>> Sip-implementors@lists.cs.columbia.edu >>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>>> >>>> -- >>> >>> With Regards >>> >>> Arun A. Tagare >>> +91 9449 029729 >>> ___ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> -- > > With Regards > > Arun A. Tagare > +91 9449 029729 > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Sip-implementors Digest, Vol 81, Issue 4
I am not a list administrator, but speaking as a civilian: I think we have been patient, but the time is nigh to mute this subscriber. On 1/8/21 1:12 AM, supp...@advisory24.vip wrote: Hi Sip-implementors, May I have your order number please? And please offer the email address and full name that you filled in when you made this order on our website. So I can check it for you. Cathy Lin On Fri, 8 Jan at 1:23 AM , supp...@advisory24.vip wrote: Thank you for contacting us! We have received the email. We are really sorry that we're off work now. Our working time is from 10am to 7pm (GMT 9), Mon to Fri. Please do not worry. We will arrange a dedicated customer service to solve your problem within 12 hours. We will try our best to help you. Have a nice day! ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] What
Yeah, I’d say that pretty much sums up the global state of affairs right now — the envelope sender name and the enquiry alike. An icon of our times. Flaming Pizza asking “what?”, but sans question mark. That’s about damn right. — Sent from mobile, with due apologies for brevity and errors. > On Apr 27, 2020, at 8:37 AM, Flaming Pizza wrote: > > What > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Proxy handling of in dialogue request
On Fri, Mar 20, 2020 at 02:37:04PM -0400, Paul Kyzivat wrote: > On 3/20/20 1:22 PM, Alex Balashov wrote: > > The proxy will send the request onward to the next Route hop. If no further > > Route hops are available, it will consume the domain portion of the Request > > URI and send the request to that. > > For the complete story, *carefully* read section 16 of RFC3261. There is a Agreed; I was trying to provide the abridged, Cliff's Notes version for what seemed like an expedient functional question. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Proxy handling of in dialogue request
The proxy will send the request onward to the next Route hop. If no further Route hops are available, it will consume the domain portion of the Request URI and send the request to that. — Sent from mobile, with due apologies for brevity and errors. > On Mar 20, 2020, at 9:23 AM, Jason Harrison > wrote: > > Hi, > > I know that a UA uses the remote target and route set to build the Route > headers and request URI. What I cannot find detail on is how a stateful proxy > will determine where to route the request. > > Does the proxy have a remote target and route set like a UA, or does it > simply use the request URI. I ask as I have a proxy server that does not > route a BYE request and I am trying to understand why > > Many thanks > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Query on SIP 488 response
Isn't this what late offers are meant to accomplish? Empty (no SDP) INVITE --> <-- 200 OK with SDP offer end-to-end ACK with SDP answer --> -- Alex On Sat, Dec 14, 2019 at 11:31:50PM -0600, Ranjit Avasarala wrote: > Hi > I have a scenario where the terminating device responds with SIP 488 Not > Acceptable here response. It is understood that the terminating device > does not support any of the codecs that the incoming INVITE has. > > this issue occurred when a landline called VoLTE device and the > intermediate MSC/MGCF translated the SS7 message to SIP INVITE and put the > codecs it supports. So since the terminating device does not support any > of the listed codecs in SIP INVITE SDP offer, it responded with 488 response > > So my query is - is there a way the terminating device could indicate the > list of codecs it supports in 488 response? > > Thanks > Ranjit > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] The purpose of late offers
Hi Roman, On Tue, Apr 23, 2019 at 05:33:37PM -0400, Roman Shpount wrote: > The most basic use case is click-to-call scenario. You have a web site or > an application that imitates a call between two SIP end points. User clicks > the web site which causes some sort of SIP application server to send an > INVITE without an offer sent to SIP end point 1. SIP application server > gets the answer with the SDP offer in 200 OK response to the initial INVITE > to end point 1, and then sends this offer to SIP end point 2. SIP End point > 2 answers the call with answer in the SDP in 200 OK response. SIP > Application server send the answer from end point 2 in ACK to SIP end point > 1. As a result, SIP signaling flow goes through SIP application server, but > media goes direct between SIP end points 1 and 2. I think I'm starting to understand what you and Paul are saying. There's nothing to offer in the initial INVITE, so you're asking one of the endpoints to provide the offer that starts the process instead. That seems obvious in hindsight, but I hadn't really considered it, since most of the click-to-call type scenarios I'm familiar with use the INVITE-hold-REFER approach. Thanks a lot, guys! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] The purpose of late offers
I still don't get it, I'm sorry: On Tue, Apr 23, 2019 at 05:34:21PM -0400, Paul Kyzivat wrote: > 1) it doesn't have any idea what codecs, or even what media, either of > the endpoints support. Yes, but how does a late offer confer this knowledge in some materially different way to a normal one? > 2) since it isn't planning on terminating the media it has no media > address to include in an initial offer. If it isn't planning on terminating the media, why wouldn't it just pass through the SDP offer from the caller as-is, as any proxy or B2BUA (sans integrated media apparatus) would? In other words, what exactly is being accomplished for the benefit of a third-party call controller via a late offer that can't be accomplished via a normal one? -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] The purpose of late offers
Paul, Why can’t it do that with an offer in the initial invite? — Sent from mobile, with due apologies for brevity and errors. > On Apr 23, 2019, at 5:10 PM, Paul Kyzivat wrote: > > Alex, > > A classic use case is 3PCC: A device in the middle wants to broker a call > between two other endpoints. A priori it doesn't know the capabilities of > either of those endpoints, and doesn't want to put itself in the media path > as a transcoder. So it asks one end to provide an offer so it can offer that > to the other end. > >Thanks, > Paul > >> On 4/23/19 1:48 PM, Alex Balashov wrote: >> Hi, >> Trying to fill a gaping hole in my knowledge: >> What is the actual purpose of late SDP offers (no SDP in initial INVITE, >> SDP offer in 2xx reply, SDP answer in end-to-end ACK)? >> RFC 3261 mentions them, of course, but I’ve only ever seen them used in >> Cisco (CCM and IOS voice gateway) land. >> I understand that this puts some control in the hands of the caller - it >> gives the caller the flexibility to respond based on the callee's SDP >> offer more 'flexibly', since it doesn't have to tip its hand about what >> it wants first. >> But from what I understand, an SDP stanza is, in principle, a statement >> about what / how each endpoint wants to receive, not send. Right? I am >> aware that there are some cases where, as a matter of convention more so >> than standardisation, some inferences about sending intentions are >> permitted on the basis of an SDP advertisement -- such as the 183 early >> media case. >> Still, in principle, SDP is about what I want to receive and how I want >> to receive it, I thought. And in principle, any session can involve >> wildly asymmetric and non-isomorphic media stream characteristics, i.e. >> two different codecs, packetisation durations, etc. on the respective >> legs. >> If so, what purpose does it serve for the caller to not have to tip its >> hand preemptively about what codecs it is willing to accept, for >> example? >> Does it mirror some PSTN interoperability need? A lot of the discussion >> around it seems to be in the context of third-party call control (3pcc), >> but the exact connection is unilluminated, and in any case, that's not a >> concept I understand particularly well. >> Much technical discussion exists online about what it does and why it >> needs to be supported: it allows the caller to respond flexibly based on >> the callee’s offer. But I can't find a word about why one might actually >> want to do that, what sort of scenario it is meant to support, or >> otherwise anything about the underlying philosophical motivation. >> Any insight is appreciated! >> -- Alex > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] The purpose of late offers
Hi Liviu, Thank you for your answer. However, I’m afraid I still don’t quite understand — perhaps it is a matter of being thick-skulled, and if so, for that I apologise in advance. What exactly can be remediated by the caller that cannot be addressed by the parties simply agreeing on a codec through the normal initial invite offer process? The only scenario I can think of offhand is if the caller wishes to truly constrain the stream to a single codec, but is flexible about what codec that should be—just that there is a policy of settling on just one. But I am unsure of why this would be practically desirable. — Sent from mobile, with due apologies for brevity and errors. > On Apr 23, 2019, at 3:37 PM, Liviu Chircu wrote: > > Hi Alex, > > In my experience, late SDP negotiation has proved to be an essential > mechanism for codec transcoding. For example, given this setup: > > UA-1B2BUA UA-2 > | INVITE | INVITE| > |-->|->| > | (offer)| (empty) | > | || > | |200 OK | > | |<-| > | | (offer) | > | | | > > the importance of late SDP offers becomes immediately obvious. By > removing the outgoing SDP on the B leg and receiving yet another SDP offer > from UA-2, the B2BUA puts itself in a position where it has a high degree > of control over the session setup. Some ideas which come to mind: > > * the ability to intersect codecs > * the ability to detect codec incompatibilities and remediate, through > transcoding hardware/software, a session setup which would have otherwise > ended prematurely with a 488 (Not Acceptable Here) > > Best regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > >> On 23.04.2019 20:48, Alex Balashov wrote: >> Hi, >> >> Trying to fill a gaping hole in my knowledge: >> >> What is the actual purpose of late SDP offers (no SDP in initial INVITE, >> SDP offer in 2xx reply, SDP answer in end-to-end ACK)? >> >> RFC 3261 mentions them, of course, but I’ve only ever seen them used in >> Cisco (CCM and IOS voice gateway) land. >> >> I understand that this puts some control in the hands of the caller - it >> gives the caller the flexibility to respond based on the callee's SDP >> offer more 'flexibly', since it doesn't have to tip its hand about what >> it wants first. >> >> But from what I understand, an SDP stanza is, in principle, a statement >> about what / how each endpoint wants to receive, not send. Right? I am >> aware that there are some cases where, as a matter of convention more so >> than standardisation, some inferences about sending intentions are >> permitted on the basis of an SDP advertisement -- such as the 183 early >> media case. >> >> Still, in principle, SDP is about what I want to receive and how I want >> to receive it, I thought. And in principle, any session can involve >> wildly asymmetric and non-isomorphic media stream characteristics, i.e. >> two different codecs, packetisation durations, etc. on the respective >> legs. >> >> If so, what purpose does it serve for the caller to not have to tip its >> hand preemptively about what codecs it is willing to accept, for >> example? >> >> Does it mirror some PSTN interoperability need? A lot of the discussion >> around it seems to be in the context of third-party call control (3pcc), >> but the exact connection is unilluminated, and in any case, that's not a >> concept I understand particularly well. >> >> Much technical discussion exists online about what it does and why it >> needs to be supported: it allows the caller to respond flexibly based on >> the callee’s offer. But I can't find a word about why one might actually >> want to do that, what sort of scenario it is meant to support, or >> otherwise anything about the underlying philosophical motivation. >> >> Any insight is appreciated! >> >> -- Alex >> > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] The purpose of late offers
Hi, Trying to fill a gaping hole in my knowledge: What is the actual purpose of late SDP offers (no SDP in initial INVITE, SDP offer in 2xx reply, SDP answer in end-to-end ACK)? RFC 3261 mentions them, of course, but I’ve only ever seen them used in Cisco (CCM and IOS voice gateway) land. I understand that this puts some control in the hands of the caller - it gives the caller the flexibility to respond based on the callee's SDP offer more 'flexibly', since it doesn't have to tip its hand about what it wants first. But from what I understand, an SDP stanza is, in principle, a statement about what / how each endpoint wants to receive, not send. Right? I am aware that there are some cases where, as a matter of convention more so than standardisation, some inferences about sending intentions are permitted on the basis of an SDP advertisement -- such as the 183 early media case. Still, in principle, SDP is about what I want to receive and how I want to receive it, I thought. And in principle, any session can involve wildly asymmetric and non-isomorphic media stream characteristics, i.e. two different codecs, packetisation durations, etc. on the respective legs. If so, what purpose does it serve for the caller to not have to tip its hand preemptively about what codecs it is willing to accept, for example? Does it mirror some PSTN interoperability need? A lot of the discussion around it seems to be in the context of third-party call control (3pcc), but the exact connection is unilluminated, and in any case, that's not a concept I understand particularly well. Much technical discussion exists online about what it does and why it needs to be supported: it allows the caller to respond flexibly based on the callee’s offer. But I can't find a word about why one might actually want to do that, what sort of scenario it is meant to support, or otherwise anything about the underlying philosophical motivation. Any insight is appreciated! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Routing of ACK
On Mon, Feb 11, 2019 at 03:50:01PM +1300, David Cunningham wrote: > Is that the case always, or only when they're in response to a 200 OK? There are two kinds of ACKs; end-to-end ACKs (in response to dialog-establishing 2xx responses of an invite transaction), and hop-by-hop ACKs (in response to negative transaction replies which require a reliable acknowledgment). The latter are independently emitted on a hop-by-hop basis, so every proxy in the chain would emit its own downstream while absorbing the upstream ones. But in answer to your question, they are still requests, not replies. Only replies are replies: SIP/2.0 xxx Reason String -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Routing of ACK
On Mon, Feb 11, 2019 at 02:28:51PM +1300, David Cunningham wrote: > Thank you. This is where I easily get mixed up, because an ACK sounds like > it should be a reply to the 200 OK. That's understandable. And ACKs are, of course, unusual. But they are certainly requests in their own right, not replies. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Routing of ACK
On Mon, Feb 11, 2019 at 02:16:50PM +1300, David Cunningham wrote: > Thank you. So I was correct other than mixing up the Route and Via headers. > Some day I'll get them right... :-) The Via headers determine the path traversed by replies to a request. They do not influence request routing, including that of in-dialog requests. So, for example, with an initial INVITE that traverses a chain of proxies which do _not_ add Record-Route headers, subsequent in-dialog requests (including the e2e ACK) will go directly to the remote target (Contact). However, the replies within that INVITE transaction will still traverse the entire chain on their way back to the recipient, because the INVITE will arrive at its final destination with a stack of Via droppings added by every intermediate proxy. But this has no bearing on future requests. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Routing of ACK
On Mon, Feb 11, 2019 at 02:08:18PM +1300, David Cunningham wrote: > OK, so the Contact is the address on the envelope, but the postal service > should actually send it through the chain of Route headers? Yes, but once the request exits the last proxy, that last proxy should set the domain part of the request URI (the remote Contact) as its next hop. > Our issue is that the device is sending the ACK directly to the Contact > address, but the Contact address doesn't support TLS, which is why we need > it to go through the proxy listed in the route set. Yes, that's wrong. The e2e ACK should follow the route set. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Routing of ACK
Hello, An end-to-end ACK should be sent to the Contact in the 200 OK. The actual network and transport-layer destination will differ due to the intermediate Record-Route hops. In RFC parlance, this is known as the "remote target" of the dialog. The ACK is in substance an in-dialog request, so the routing would be the same as for a reinvite or a BYE: Record-Route hops are converted to Route headers and stripped off by intermediate proxies, but the request URI is set to the remote Contact URI and that is the final hop. -- Alex On Mon, Feb 11, 2019 at 01:48:06PM +1300, David Cunningham wrote: > Hello, > > Could someone please confirm the correct routing of an ACK? > A device receives the following 200 OK. Should the ACK it sends in response > be sent to the first Via address? I believe that sending it to the Contact > address is incorrect? If anyone happens to know the part of the RFC that > specifies this it would be very helpful. > Thank you in advance. > > SIP/2.0 200 OK > Via: SIP/2.0/TLS xx.xx.102.10:5061;rport=51582;branch=z9hG4bK85341894 > Record-Route: > Record-Route: > From: Test ;tag=Nf5GGRC3g6plN!8si1807E2D3ad0440e > To: ;tag=as448937d5 > Call-ID: 105176...@xx.xx.102.10 > CSeq: 5295 INVITE > Server: ES8 > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE > Supported: replaces, timer > Contact: > Content-Type: application/sdp > Content-Length: 337 > > -- > David Cunningham, Voisonics Limited > http://voisonics.com/ > USA: +1 213 221 1092 > New Zealand: +64 (0)28 2558 3782 > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
On Wed, Jan 30, 2019 at 10:23:21PM -0500, Dale R. Worley wrote: > Perhaps the endpoint simply means "I received CustomAttribute:GID in > the offer." Yep, that's the interpretive frame in which I was contemplating the problem. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
Hello, On Tue, Jan 29, 2019 at 11:21:01AM -0500, Paul Kyzivat wrote: > 5.13 says: "Attributes MUST be registered with IANA", so why do you > say this isn't illegal? Upon reflection, you are certainly correct. I suppose the notion of legality I had in mind was implicitly to do with grammatical validity / request intelligibility rather than policy. So, if the attribute is not registered and if the foregoing applies to unsupported but registered attributes, and is therefore illegal, then, in the context of one of those acrimonious "how dare you say I'm not following the standards?" disputes, does this--in any _reasonable_ way, taking purely political phenomena out of it--open the door to the receiver/answerer vendor arguing that an endpoint making use of an unregistered attribute (that is to say, illegally so) is not justified in expecting predictable or standards-prescribed results in the answer? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Reflection of non-registered SDP attributes
Hi, I am using a media relay which implements some internal loop detection by adding a non-IANA-registered SDP attribute to any offer or answer that passes through it: a=CustomAttribute:GUID >From what I understood from RFC 4566 § 5.13, this isn't illegal, but such an attribute must be ignored. Now, there is a particular type of endpoint in use in this environment which takes that attribute from an incoming initial INVITE--which is, by definition, not locally intelligible--and copies it dumbly into its 2xx/SDP answer. Commonsensically, this seems like broken behaviour; if it doesn't understand the attribute, it must be ignored, per § 5.13. Beyond that, is there any specific proscription against doing this in the standard? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?
BUY message? What is this, Broadsoft? :-) On Fri, Dec 21, 2018 at 01:29:26PM -0500, Roman Shpount wrote: > You will need to send the BUY message. 404 response only cancels the > re-INVITE transaction, not the call. This being said, most SIP > implementations will hang up the call (send BUY) when they receive 404 > response to a re-INVITE. > > Regards, > _ > Roman Shpount > > > On Fri, Dec 21, 2018 at 12:54 PM Moy Amiga wrote: > > > Hi. > > > > I Have a question. > > When I have a already established call, and we send a Re-Invite, if this > > Re-Invite was rejected with 404. > > To finish the call, we need a BYE message or only with this reject 404 the > > session is considered canceled? > > > > Thank you and best regards > > > > > > -- > > *Moisés Amiga* > > > > *Voice Operations* > > ___ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Appropriate back-off response for overly frequent registrations
On Thu, Nov 29, 2018 at 05:35:19PM -0500, Roman Shpount wrote: > Some applications do not support keep alive, so it is up to you to > either not support such devices or handle frequent REGISTER messages > gracefully. Our position is to not support such devices. Now that the philosophical question is out of the way, what's the right SIP response? ;-) -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Appropriate back-off response for overly frequent registrations
Yep, we agree. So the question is what the safest response would be to send for the largest number of endpoints, such that they don't mark the trunk as being out of service/decide that the gateway is permanently unreachable, and actually re-register as their binding comes up for renewal. On Thu, Nov 29, 2018 at 10:48:46PM +0100, Philipp Schöning wrote: > There is no need to send REGISTER-Requests this often. > This will generate unnecessary load on the application level. > > If UDP is used for transport, empty UDP packets can be sent to keep the > NAT-binding alive. > When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to > keep the NAT-binding alive. > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Appropriate back-off response for overly frequent registrations
On Thu, Nov 29, 2018 at 02:42:26PM -0500, Roman Shpount wrote: > Some devices do this to keep a pinhole in NAT firewall open. Pleases see if > you can enable keep-alive on your proxy and the device for the same purpose > (https://tools.ietf.org/html/rfc5626#section-3.5). Yep, they may. But a few seconds is simply too aggressive. > We have successfully used 480 with "Retry-After" to reduce the load on the > proxy after network connectivity disruption, so this should work for your > purpose, but I would still suggest addressing the root cause. Other option > is too have proxy to use some sort of in-memory DB to efficiently handle > frequent registrations for devices that do no support SIP keep alive. I agree. At this point it's a matter of principle rather than unmanageable load. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Appropriate back-off response for overly frequent registrations
Hi, I have a SIP registrar with a policy-based registration interval floor of 60 seconds. One would expect that this means most devices would register with such an expiry time, and then refresh the registration a few seconds before it expires. However, there are numerous endpoints out there which refresh the registration at much higher frequencies, sometimes as low as every few seconds. That is to say, they request an interval of 60 seconds or more, but re-register every 2-5 seconds. I am putting in a mechanism to stop this, as it generates unnecessary load and is generally poor form. I am not sure, however, what the appropriate SIP response to these endpoints should be. My best guess is that '480 Temporarily Unavailable' with a 'Retry-After' header would make the most sense, but the language in the RFC is ambiguous as to whether this response is only contemplated in the context of a 'call' as opposed to a registration flow. Your insight is as always appreciated! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RTP with wrong payload
Correct -- if the party receiving the G.722 packets did not advertise support for the G.722 payload type in its SDP stanza, it should just ignore them if they arrive anyway. On Thu, Nov 15, 2018 at 06:21:14AM +, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > I should have given more details, in the example I gave there was actual a > couple of G.722 packets that was marked with payload type G.722 received in a > session where G.711A(PCMA/8000) was established as the agreed codec, the > receiving PBX did not have support for G.722. > As I interpret RFC 3550 the PBX should drop the G.722 packets and let the > session continue, and same applies also in case where G.722 is supported by > PBX, am I wrong ? > BR/pj > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Dale R. > Worley > Sent: den 15 november 2018 05:10 > To: Paul Heitkemper > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] RTP with wrong payload > > Paul Heitkemper writes: > > RFC 3550 Section 5.1 > > > > " A receiver MUST ignore packets with payload types that it does not > > understand." > > Though this rule is based on the payload type code, and not the encoding. > The original post says only that the packets contain G.722 data, but if that > data is marked with the payload type code that was negotiated for G.711A, the > recipient will try to decode it as G.711A. > Perhaps the recipient can determine that the data is invalid (as G.711A) and > discard it, but more likely it will decode it into some sort of noise which > it will present to the user. > > Dale > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Sip proxies and REST endpoints
It sounds like Kamailio would do the trick for you, since it has a number of HTTP clients: https://kamailio.org/docs/modules/5.1.x/modules/http_client.html https://kamailio.org/docs/modules/5.1.x/modules/http_async_client.html And even a nice module for parsing JSON: https://kamailio.org/docs/modules/5.1.x/modules/jansson.html -- Alex On Thu, Nov 01, 2018 at 05:15:31PM +, n...@spearheadcommunications.ca wrote: > Hi I have a question regarding open source SIP proxies, I want to allow data > that sits on a REST endpoint to the SIP headers as they flow through the > proxy. Currently a Cisco CME is connected to a SIP trunk. Can we have a CME > connect to the proxy, and the proxy to the SIP trunk. The SIP proxy doesn’t > need to be production grade, but it does need to be flexible – ideally able > to run code to connect to a REST endpoints and pull that into the proxy for > inclusion in the SIP headers. > > > > > Which RFP should l investigate and what are the experiences with running sip > proxies to REST endpoints. > > > > > > > Thanks, Michael > > > > > > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Offer/answer model in early media with forking
On Mon, Jul 16, 2018 at 11:01:30PM -0400, Dale R. Worley wrote: > > Well, the first branch is disposed of with a 5xx reply. But the UAC > > cancels nothing, in spite of getting two different early responses > > from two different dialogs. > > You should have mentioned the 5xx reply in your original message, as > that's how the first dialog ends. But the 5xx reply is caught by the proxy, and never propagated to the caller. The caller just sees a 183 with one To-tag, then a 183 and a 200 OK with a different To-tag. > A lot of low-budget UAs handle many situations incorrectly. Ultimately, > the answer is to avoid using them, because otherwise you're spending all > your time adjusting your software to try to figure out what the UA is > and avoiding its flaws. That's certainly true enough! :) -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Offer/answer model in early media with forking
Well, the first branch is disposed of with a 5xx reply. But the UAC cancels
nothing, in spite of getting two different early responses from two different
dialogs.
Granted, I haven't tried waiting around for 3 minutes or whatever the maximum
prescribed early/alerting state is.
On July 16, 2018 6:24:35 PM EDT, Paul Kyzivat wrote:
>On 7/16/18 2:00 PM, Alex Balashov wrote:
>> It should be noted that the UA with which I am testing (Freeswitch)
>does
>> not CANCEL or otherwise hang up the first dialog.
>
>In this case, since the proxy did the forking, it SHOULD (MUST?) send a
>
>CANCEL. So it will probably be ok.
>
> Thanks,
> Paul
>
>> On Mon, Jul 16, 2018 at 01:56:34PM -0400, Alex Balashov wrote:
>>
>>> Oh, yes — they're different dialogs, for sure. I just wasn't sure if
>>> that would nevertheless pose a problem for some low-budget UAs.
>>>
>>> On Mon, Jul 16, 2018 at 01:47:32PM -0400, Paul Kyzivat wrote:
>>>
>>>> On 7/16/18 1:17 PM, Alex Balashov wrote:
>>>>> Hi,
>>>>>
>>>>> I have a scenario where a call is forked through a proxy to an
>early
>>>>> media announcement server and then subsequently to a SIP provider
>for
>>>>> actual termination.
>>>>>
>>>>> Due to the way the RTP relay works on the server side, this
>results in
>>>>> two different SDP offers from the two respective outgoing branches
>being
>>>>> sent back to the caller:
>>>>>
>>>>> 1. 183+SDP on branch #1.
>>>>>
>>>>> 2. 183+SDP' on branch #2.
>>>>> 200 OK+SDP' on branch #2.
>>>>
>>>> These are both sent back to the UAC?
>>>>
>>>> If so, these should arrive with different to-tags, and so will
>establish
>>>> distinct early dialogs. Those can coexist. Then when the 200
>arrives,
>>>> (regardless of which dialog it comes on), the UAC should send a
>CANCEL on
>>>> the other dialog (to the Contact URI for that dialog. Or it can
>send a BYE.
>>>>
>>>> There is a race condition where you get a 200 on *both* early
>dialogs. In
>>>> that case you have two separate calls to deal with. Then you can
>send a BYE
>>>> on one of them, or manage them both separately, or treat them as a
>>>> conference, or whatever you want.
>>>>
>>>> OTOH, if perchance the two 183 responses have the *same* to-tag,
>then you
>>>> have an error situation.
>>>>
>>>>Thanks,
>>>>Paul
>>>>
>>>>> I am not sure offhand whether this is a protocol semantics
>violation. On
>>>>> the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE")
>says:
>>>>>
>>>>> If the initial offer is in an INVITE, the answer MUST be in a
>>>>> reliable non-failure message from UAS back to UAC which is
>>>>> correlated to that INVITE. For this specification, that is
>>>>> only the final 2xx response to that INVITE. That same exact
>>>>> answer MAY also be placed in any provisional responses sent
>>>>> prior to the answer. The UAC MUST treat the first session
>>>>> description it receives as the answer, and MUST ignore any
>>>>> session descriptions in subsequent responses to the initial
>>>>> INVITE.
>>>>>
>>>>> So, I always understood that the first answer is the final answer,
>>>>> absent a session-updating request cycle. On the other hand, RFC
>3960
>>>>> ("Early Media and Ringing Tone Generation in the Session
>Initiation
>>>>> Protocol (SIP)") Section 4 says:
>>>>>
>>>>> The application server model consists of having the UAS
>behave as an
>>>>> application server to establish early media sessions with the
>UAC.
>>>>> The UAC indicates support for the early-session disposition
>type
>>>>> (defined in [2]) using the early-session option tag. This
>way, UASs
>>>>> know that they can keep offer/answer exchanges for early
>media
>>>>> (early-session disposition type) separate from regular media
>(session
>>>>> disposition type).
>>>>>
>>>>> I take this, along with RFC 3959 Section 3, to imply an amendment
>to
>>>>> 3261 § 13.2.1, but I'm not sure.
Re: [Sip-implementors] Offer/answer model in early media with forking
It should be noted that the UA with which I am testing (Freeswitch) does
not CANCEL or otherwise hang up the first dialog.
On Mon, Jul 16, 2018 at 01:56:34PM -0400, Alex Balashov wrote:
> Oh, yes — they're different dialogs, for sure. I just wasn't sure if
> that would nevertheless pose a problem for some low-budget UAs.
>
> On Mon, Jul 16, 2018 at 01:47:32PM -0400, Paul Kyzivat wrote:
>
> > On 7/16/18 1:17 PM, Alex Balashov wrote:
> > > Hi,
> > >
> > > I have a scenario where a call is forked through a proxy to an early
> > > media announcement server and then subsequently to a SIP provider for
> > > actual termination.
> > >
> > > Due to the way the RTP relay works on the server side, this results in
> > > two different SDP offers from the two respective outgoing branches being
> > > sent back to the caller:
> > >
> > > 1. 183+SDP on branch #1.
> > >
> > > 2. 183+SDP' on branch #2.
> > > 200 OK+SDP' on branch #2.
> >
> > These are both sent back to the UAC?
> >
> > If so, these should arrive with different to-tags, and so will establish
> > distinct early dialogs. Those can coexist. Then when the 200 arrives,
> > (regardless of which dialog it comes on), the UAC should send a CANCEL on
> > the other dialog (to the Contact URI for that dialog. Or it can send a BYE.
> >
> > There is a race condition where you get a 200 on *both* early dialogs. In
> > that case you have two separate calls to deal with. Then you can send a BYE
> > on one of them, or manage them both separately, or treat them as a
> > conference, or whatever you want.
> >
> > OTOH, if perchance the two 183 responses have the *same* to-tag, then you
> > have an error situation.
> >
> > Thanks,
> > Paul
> >
> > > I am not sure offhand whether this is a protocol semantics violation. On
> > > the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
> > >
> > > If the initial offer is in an INVITE, the answer MUST be in a
> > > reliable non-failure message from UAS back to UAC which is
> > > correlated to that INVITE. For this specification, that is
> > > only the final 2xx response to that INVITE. That same exact
> > > answer MAY also be placed in any provisional responses sent
> > > prior to the answer. The UAC MUST treat the first session
> > > description it receives as the answer, and MUST ignore any
> > > session descriptions in subsequent responses to the initial
> > > INVITE.
> > >
> > > So, I always understood that the first answer is the final answer,
> > > absent a session-updating request cycle. On the other hand, RFC 3960
> > > ("Early Media and Ringing Tone Generation in the Session Initiation
> > > Protocol (SIP)") Section 4 says:
> > >
> > > The application server model consists of having the UAS behave as an
> > > application server to establish early media sessions with the UAC.
> > > The UAC indicates support for the early-session disposition type
> > > (defined in [2]) using the early-session option tag. This way, UASs
> > > know that they can keep offer/answer exchanges for early media
> > > (early-session disposition type) separate from regular media (session
> > > disposition type).
> > >
> > > I take this, along with RFC 3959 Section 3, to imply an amendment to
> > > 3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
> > > will handle this situation.
> > >
> > > Any insight would be appreciated!
> > >
> >
> > ___
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Offer/answer model in early media with forking
Oh, yes — they're different dialogs, for sure. I just wasn't sure if
that would nevertheless pose a problem for some low-budget UAs.
On Mon, Jul 16, 2018 at 01:47:32PM -0400, Paul Kyzivat wrote:
> On 7/16/18 1:17 PM, Alex Balashov wrote:
> > Hi,
> >
> > I have a scenario where a call is forked through a proxy to an early
> > media announcement server and then subsequently to a SIP provider for
> > actual termination.
> >
> > Due to the way the RTP relay works on the server side, this results in
> > two different SDP offers from the two respective outgoing branches being
> > sent back to the caller:
> >
> > 1. 183+SDP on branch #1.
> >
> > 2. 183+SDP' on branch #2.
> > 200 OK+SDP' on branch #2.
>
> These are both sent back to the UAC?
>
> If so, these should arrive with different to-tags, and so will establish
> distinct early dialogs. Those can coexist. Then when the 200 arrives,
> (regardless of which dialog it comes on), the UAC should send a CANCEL on
> the other dialog (to the Contact URI for that dialog. Or it can send a BYE.
>
> There is a race condition where you get a 200 on *both* early dialogs. In
> that case you have two separate calls to deal with. Then you can send a BYE
> on one of them, or manage them both separately, or treat them as a
> conference, or whatever you want.
>
> OTOH, if perchance the two 183 responses have the *same* to-tag, then you
> have an error situation.
>
> Thanks,
> Paul
>
> > I am not sure offhand whether this is a protocol semantics violation. On
> > the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
> >
> > If the initial offer is in an INVITE, the answer MUST be in a
> > reliable non-failure message from UAS back to UAC which is
> > correlated to that INVITE. For this specification, that is
> > only the final 2xx response to that INVITE. That same exact
> > answer MAY also be placed in any provisional responses sent
> > prior to the answer. The UAC MUST treat the first session
> > description it receives as the answer, and MUST ignore any
> > session descriptions in subsequent responses to the initial
> > INVITE.
> >
> > So, I always understood that the first answer is the final answer,
> > absent a session-updating request cycle. On the other hand, RFC 3960
> > ("Early Media and Ringing Tone Generation in the Session Initiation
> > Protocol (SIP)") Section 4 says:
> >
> > The application server model consists of having the UAS behave as an
> > application server to establish early media sessions with the UAC.
> > The UAC indicates support for the early-session disposition type
> > (defined in [2]) using the early-session option tag. This way, UASs
> > know that they can keep offer/answer exchanges for early media
> > (early-session disposition type) separate from regular media (session
> > disposition type).
> >
> > I take this, along with RFC 3959 Section 3, to imply an amendment to
> > 3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
> > will handle this situation.
> >
> > Any insight would be appreciated!
> >
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Offer/answer model in early media with forking
Hi,
I have a scenario where a call is forked through a proxy to an early
media announcement server and then subsequently to a SIP provider for
actual termination.
Due to the way the RTP relay works on the server side, this results in
two different SDP offers from the two respective outgoing branches being
sent back to the caller:
1. 183+SDP on branch #1.
2. 183+SDP' on branch #2.
200 OK+SDP' on branch #2.
I am not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag. This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.
Any insight would be appreciated!
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SIP 422 and RFC 4028
Yeah, that's true. It's easily forgot in an applied sense because the mainstream FOSS proxies, e.g. Kamailio, both support dialog state tracking and issuing various kinds of in-dialog DPD requests (e.g. OPTIONS), and even support spoofing BYEs to hang up a dead call if DPD requests go unreplied. But of course, that's radioactively non-standards-compliant. :-) On July 3, 2018 10:20:41 AM EDT, Paul Kyzivat wrote: >On 7/3/18 3:53 AM, Alex Balashov wrote: >> No, it's not illegal to retry a call to the same gateway (in case of >6xx response). >> >> Nor is it illegal to reject it. :-) >> >> My experience in an applied sense with SSTs (SIP Session Timers) is >that they are poorly supported, seemingly due to all the state-keeping >involved. Many UAs commit to a refresher role, for instance, but don't >actually issue the reinvites to refresh. >> >> Instead, it is a more commonplace to approach to just use >nullary-change reinvites for signalling-level DPD (dead peer >detection), without the baggage of SSTs. So for instance, there are a >lot of carriers out there whose equipment will just send you a reinvite >every 15 minutes to check if you're alive, quite regardless of any >SSTs, roles, support for SSTs, etc. > >I think people forget that UAs have no need of session timers, since >they can do as you say, whenever they wonder about the status of the >session. > >The real point of session timers is in support of proxies in the >signaling path. If they want to keep session state, then they have no >way to know when to clear that state if they see no signaling for a >long >time. The session timers give them a way to ask the UAs to help them >out. > >More in another reply. > > Thanks, > Paul -- Alex -- Sent via mobile, please forgive typos and brevity. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SIP 422 and RFC 4028
No, it's not illegal to retry a call to the same gateway (in case of 6xx response). Nor is it illegal to reject it. :-) My experience in an applied sense with SSTs (SIP Session Timers) is that they are poorly supported, seemingly due to all the state-keeping involved. Many UAs commit to a refresher role, for instance, but don't actually issue the reinvites to refresh. Instead, it is a more commonplace to approach to just use nullary-change reinvites for signalling-level DPD (dead peer detection), without the baggage of SSTs. So for instance, there are a lot of carriers out there whose equipment will just send you a reinvite every 15 minutes to check if you're alive, quite regardless of any SSTs, roles, support for SSTs, etc. -- Alex -- Sent via mobile, please forgive typos and brevity. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] To tag in 407 challenges
My perplexion is rooted precisely in the fact that no dialog has been established upon a negative final reply to the invite transaction. On March 25, 2018 6:27:03 PM EDT, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: >On 3/25/18 5:26 PM, Alex Balashov wrote: >> Hi, >> >> Are 407 challenges meant to have a To tag? If so, I can't find the >> rationale in 3261. Any pointers would be appreciated. > >(working from memory) > >An argument against to-tag in 407 would presumably apply equally to any > >3xx, 4xx, 5xx, or 6xx. One could argue that the to-tag is for >establishing a dialog, and if no dialog has been established then it >isn't needed. > >OTOH, AFAIK the requirement to include a to-tag is across the board. > > Thanks, > Paul >___ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex -- Sent via mobile, please forgive typos and brevity. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] To tag in 407 challenges
Hi, Are 407 challenges meant to have a To tag? If so, I can't find the rationale in 3261. Any pointers would be appreciated. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Some TLS questions
On Wed, Nov 22, 2017 at 01:00:47AM -0500, Alex Balashov wrote: > You say Kamailio supports SNI? How? I suppose the answer lies in multiple TLS configs for each domain: https://kamailio.org/docs/modules/5.0.x/modules/tls.html#tls.p.config -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Some TLS questions
On Tue, Nov 21, 2017 at 12:13:14PM +0100, Olle E. Johansson wrote: > Propably because they don’t trust your CA. You need to install the > CA cert in the trust store on the systems you run Bria and Blink on > (and remember to remove it later) Since I wrote that, I got an authoritative certificate for the host from Comodo. Its CN happens to correspond to the serving SIP domain & canonical hostname, so I cannot tell whether the UAs properly deal with SAN. Bria and my Polycom VVX 411 validate the certificate. Bria does not, despite using OpenSSL defaults which include root CA certs/chains for several Comodo issuers. I suspect that this is an adequate bellwether of how other UAs will behave: inconsistently. I have heard it said by some that authoritative certificates from well-known CAs are not a big thing in the SIP TLS world. The folklore has it that most large service providers and enterprises run their own CAs and simply mass-provision their own certificates into devices. I cannot say if it's true. But if it is true, it would greatly differ from the practice in the WWW world, it would seem. I am also unsure as to the status of LetsEncrypt. It seems a handful of handset vendors might have been persuaded to support it. > SAN is an extension so that ONE certificate is valid for multiple names. > If you have SAN fields, the CN of the cert is ignored. > > SNI is a TLS function where the client says “I’m going to connect to > alex.domain.com <http://alex.domain.com/>” early in the TLS negotiation so > that the server > can select a valid certificate. The server now has one certificate > per domain and selects which one to use for the session. > > In summary > * SAN = One cert, many names, one server > * SNI = One cert per domain, one server Interesting. For my use-case, SNI might be more appropriate than SAN; You say Kamailio supports SNI? How? > > Interesting; so as a practical matter, it is formally acceptable to send > > a request with neither sips: scheme nor ;transport=TLS, just happen to > > send it via TLS? The only indication of transport would then be > > SIP/2.0/TLS in the Via header, no? > Right. And hopefully the server will add proper headers (what they are > without the transport flag) to the record-route and route headers. > THis is a bug in SIP. Kamailio adds RRs with ;transport=tls for the appropriate hop. > You need to look at SIP outbound so that the client opens the > connection to the server and the server has the right to use > the *very same* connection for messages to the client. Without > outbound, the server is required to open a TLS connection to the > client and vertify the client’s certificate against the target URI. I assume it is common practice to turn off verification of the client certificate? That is what I have done in my Kamailio test environment. > In summary, one can get SIP over TLS to work if you break some parts > of the RFCs and rely more on developers than the documentation from > IETF. That has been consistent with my exploration thus far. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Some TLS questions
Hello Olle, Thank you for the education! By way of further question to the list: On Sat, Nov 18, 2017 at 12:21:09PM +0100, Olle E. Johansson wrote: > They are important and indicate that further work is needed here. > Please also engage the SIPCORE wg in IETF with questions like these. I am not sure that my ignorance of SIP-TLS basics constitutes a deficiency in the work of the relevant IETF WG. > > 1. Are wildcard certificates (commonName of *.domain.com) permitted for > > SIP-TLS? > > > > RFC 5922 § 7.2 seems to suggest they are not: > > [...] > > Is this true in the wild? > Not really. I haven’t seen any server that enforces this policy. At > the time of the writing of this RFC wildcards where highly suspected > for abuse but I haven’t seen much discussions about this lately. > Propably because of SNI and SNA (see below). I am more concerned about clients (e.g. phones, softphones) not accepting this. > Server Name Indication is supported in Kamailio and is the way forward > to solve this problem. But if, as you say, the server only supports > one certificate then Subject Alt names is the way to go. Look at the > cert for Google services for an example. This means that you will have > to change certificate for every new customer, which is a bad thing. This may be getting a bit applied and away from the focus of this list, but: I successfully built (after painstaking research) a self-signed certificate with openssl last night with a CN of domain.com and SANs of sip.domain.com and sipgw.domain.com last night. It was signed by a self-signed (non-authoritative) CA I also made using the usual openssl folk traditions for that. Both Bria and Blink refused to validate the certificate, but I cannot figure out if this is because the CA is non-authoritative or because they don't recognise the SNA attributes. What is the difference between SAN and SNI? > Neither. It’s deprecated in RFC 3261 and something I’ve tried to get > interest in reinstating. We need a way to indicate TLS transport. Interesting; so as a practical matter, it is formally acceptable to send a request with neither sips: scheme nor ;transport=TLS, just happen to send it via TLS? The only indication of transport would then be SIP/2.0/TLS in the Via header, no? Why does this seem to differ for SIP over standard TCP? As far as I can see, almost all TCP-speaking UAs send ;transport=tcp. Perhaps I'm wrong. I guess RFC 3261 § 26.2.2 speaks to that. > No, any URI scheme can be carried over TLS. Many implementations look > for the TLS Naptr/SRV first and if existing always use TLS. SIPS is > required to use over a protected transport. But it’s impossible to > implement, so forget about the SIPS: uri. Thanks, that's an important point of clarity. In my particular case, I am tinkering with an implementation that provides TLS + SRTP on the "last mile" but forwards the traffic unprotected to the SIP termination supply chain, which almost universally does not generally provide transport or media security, at least not in the USA. Nevertheless, last-mile encryption is required to meet some compliance and regulatory requirements. It's absurd. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Some TLS questions
Hi, A few questions about TLS. I apologise that they're kind of idiotic, I'm new to SIP over TLS. I have been a big supporter of LetsDecrypt, a certificate authority sponsored by the NSA. :-) 1. Are wildcard certificates (commonName of *.domain.com) permitted for SIP-TLS? RFC 5922 § 7.2 seems to suggest they are not: Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com". RFC 2818 [7] (HTTP over TLS) allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 [6], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. RFC 3261 [2] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains. Is this true in the wild? If so, how to deal with a SIP server that serves multiple domains but supports only one certificate and key pair? 2. Is ';transport=tls' or ';transport=TLS' appropriate? I've seen both, but which one is correct? 3. Does a 'sips:' URI scheme imply ';transport=tls', or must the latter be explictly included? In other words, will a 'sips:' URI like 'sips:5551...@domain.com' be constructed to be 'sips:5551...@domain.com;transport=tls'? 4. Is a 'sips:' URI scheme mandatory for secure transport? What are the implications of a 'sip:' URI with ';transport=tls' affixed? 5. Is it permitted for a proxy to bend a 'sips:' Request URI scheme to 'sip:' when adapting TLS to an insecure transport? Many thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reinvite/ACK race
On Tue, Oct 31, 2017 at 10:38:00PM -0400, Dale R. Worley wrote: > As others have said, the problem must be solved by the UAs, not the > proxy. Indeed, what with possible network delays and re-sending of > lost packets, there's no way to guarantee end-to-end sequencing of > messages. Even with TCP service, there's no guarantee that none of > the intermediate proxies aren't using multiple TCP connections to > carry messages between themselves. That's certainly true. But in this case I do control the entire setup topology end-to-end, and implicit in my thesis was the desire to assert control over that over which control can be asserted. :-) > You're correct to look to 5407 (which is important enough to be known as > just "Hasebe") for guidance. And it does look like section 3.1.4 is the > relevant case, or very close to it. > >This scenario illustrates the race condition that occurs when a UAS >in the Moratorium state [having sent 2xx but not received ACK] >receives a re-INVITE sent by a UAC in the Established state. > > And as the text goes on, sending 2xx is recommended, rather than 491, > because all of the state changes within the UA associated with the first > re-INVITE have already been completed. But a 491 response is also > permissible. The reason that I did not think § 3.1.4 was exactly pertinent was due to this formulation: The UAS receives a re-INVITE (with offer2) before receiving an ACK for the ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to the ini-INVITE (F3, F5) and the dialog has already been established. (Because F5 is a retransmission of F3, SDP negotiation is not performed here.) The scenario described in the foregoing is for a reinvite occuring after an *initial* INVITE cycle but arriving before the ACK for that initial INVITE. The scenario I've got going on is a reinvite following another reinvite. As you suggest, there are few reasons to think that the reasoning should be different, or at any rate substantially different, for a consecutive reinvite vs. a reinvite following an initial INVITE. Nevertheless, that was what motivated the perception that § 3.1.4 may not speak to the fine letter of the exact scenario in play. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reinvite/ACK race
Paul, I'm not a SIP standards expert by any stretch, but yours is the interpretation I tend to favour and which sits best with me. Since in-dialog requests are originated by the dialog parties, timing issues belong with them, not with intermediate proxies IMHO. On October 31, 2017 10:50:45 AM EDT, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: >On 10/31/17 8:44 AM, Liviu Chircu wrote: >> Hi Alex, >> >> IMO, building logic into the proxy which encourages/mends the proper >> sequencing of UDP messages does nothing more than to hide the >underlying >> problem, i.e. "UDP does not guarantee message sequencing in the first > >> place" *. There is also a subtle point to be made here: your proxy's >> loosely coupled/parallelized way of handling the two transactions is >> effectively breaking the RFC some % of the time, since the proxy's TU >is >> generating a new INVITE while another INVITE transaction is in >progress >> (strictly judging by the network timestamps). > >One can argue that the proxy is doing nothing wrong and perhaps being >helpful by exposing bugs in handling of reordered UDP messages. > > Thanks, > Paul > >> * From this angle, the only sane thing left to do is to have the >proxy >> retry the re-INVITE for UASs who are properly responding with 491 and > >> propagate any other 4xx/5xx error replies back to the UAC (UA B in >our >> case) in the hope that they retry their re-INVITE. >> >> Best regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 30.10.2017 19:11, Alex Balashov wrote: >>> Hi, >>> >>> I've got a scenario like so: >>> >>> UA A -> Proxy P > UA B >>> >>> 1. UA A initiates call through Proxy P; >>> >>> 2. Dialog is established and confirmed, with Record-Route; >>> >>> 3. UA B sends reinvite #1 through P to A; >>> >>> 4. UA B sends 2xx reply; >>> >>> 5. UA B sends end-to-end ACK for reinvite #1 and almost >>> simultaneously sends reinvite #2. The temporal delta is >>> between reinvite #2 and ACK for reinvite #1 on the wire >>> is 3 ms. >>> >>> The issue is that the concurrency characteristics of proxy P are >such >>> that its worker threads are very loosely coupled, and there's no >>> synchronisation among them for message ordering. Transport is UDP, >>> naturally. >>> >>> So, the result — for all kinds of stochastic processing and >userspace >>> scheduling type reasons — is that the reinvite is forwarded first, >>> before the ACK. That leads to a 500 / 491 scenario UA A. >>> >>> Is there any general guidance on what to do with these scenarios? I >>> looked at RFC 5407 § 3.1.4, which appears to describe a similar, but >not >>> identical scenario involving an initial INVITE and subsequent >reinvite. >>> As far as I can tell, the recommendation in that standard is "space >the >>> messaging out more in time". >>> >>> Switching to TCP would presumably help, since any given flow would >>> involve a single connection to a single worker thread and the >transport >>> would guarantee ordering. However, that's not really feasible in >this >>> implementation for a host of reasons. >>> >>> Any other thoughts welcome! >>> >>> Cheers, >>> >>> -- Alex >>> >> >> ___ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >___ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex -- Sent via mobile, please forgive typos and brevity. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reinvite/ACK race
Piece of errata here (always when I'm typing): On Mon, Oct 30, 2017 at 01:11:50PM -0400, Alex Balashov wrote: > Hi, > > I've got a scenario like so: > >UA A -> Proxy P > UA B > > 1. UA A initiates call through Proxy P; > > 2. Dialog is established and confirmed, with Record-Route; > > 3. UA B sends reinvite #1 through P to A; > > 4. UA B sends 2xx reply; In #4, UA A is definitely sending the 2xx reply. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Reinvite/ACK race
Hi, I've got a scenario like so: UA A -> Proxy P > UA B 1. UA A initiates call through Proxy P; 2. Dialog is established and confirmed, with Record-Route; 3. UA B sends reinvite #1 through P to A; 4. UA B sends 2xx reply; 5. UA B sends end-to-end ACK for reinvite #1 and almost simultaneously sends reinvite #2. The temporal delta is between reinvite #2 and ACK for reinvite #1 on the wire is 3 ms. The issue is that the concurrency characteristics of proxy P are such that its worker threads are very loosely coupled, and there's no synchronisation among them for message ordering. Transport is UDP, naturally. So, the result — for all kinds of stochastic processing and userspace scheduling type reasons — is that the reinvite is forwarded first, before the ACK. That leads to a 500 / 491 scenario UA A. Is there any general guidance on what to do with these scenarios? I looked at RFC 5407 § 3.1.4, which appears to describe a similar, but not identical scenario involving an initial INVITE and subsequent reinvite. As far as I can tell, the recommendation in that standard is "space the messaging out more in time". Switching to TCP would presumably help, since any given flow would involve a single connection to a single worker thread and the transport would guarantee ordering. However, that's not really feasible in this implementation for a host of reasons. Any other thoughts welcome! Cheers, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying
But to clarify my question: Regardless of whether it's a rogue standard from an IETF POV, there clearly is *some* kind of standard out there, as indicated by the number of (big) vendors who implement it in an agreed-upon way. So, what I'm trying to figure out is what that standard is and where it's defined. The Neustar documentation contains obvious cut-and-paste from an ABNF spec: calling-name-request = callee CRLF [ called CRLF ] callee =“Calling-Party” HCOLON addr-spec called =“Called-Party” HCOLON addr-spec addr-spec =SIP URI / SIPS URI / TEL URI And it does not seem thematically consistent with the general tenor of that document to suddenly break out some ABNF on their own accord. So, this syntax spec comes from *somewhere*, though no citations revealing its provenance are provided. The same kind of thing is true in all other docs on this topic from other major vendors. None of them reference anything non-generic (e.g. RFC 3265). -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying
Hi Paul, On Mon, Oct 30, 2017 at 11:04:40AM -0400, Paul Kyzivat wrote: > > As far as I know, SIP redirects are the generally accepted transport > > for generic data queries (e.g. LRN dips, CNAM) over SIP. > > Can you provide a reference to a specification for how this is done? My inspiration for this particular statement is RFC 4694. Every LNP-query-over-SIP implementation I've seen in the wild returns a 3xx redirect of some description (though exact status code does vary) with a Contact that looks like this: Contact: <sip:orig_ruri_dest;npdi;rn=14045551...@orig.ruri.domain:port> > > https://www.neustar.biz/resources/cnam/data-services-lidb-user-guide.pdf > > > > See Chapter 7 - IP-CNAM Speification (page 25). > > It looks like Neustar is acting as a quasi-standard for this mechanism. > > [...] > > > Whose proprietary information? > > Based on your own reference, looks like it is Neustar's. I'm not sure that's true. While Neustar's documentation is more elaborate than that of most service providers and softswitch vendors who offer this query mechanism, it is not substantially more authoritative. In other words, if I had linked to another vendor's documentation and you never saw Neustar's, you would most likely have concluded that the other vendor is the de facto pusher of this standard. > > Why bother with an encapsulated body, then? > > This isn't my definition so I can only speculate, but there is need > for *some* syntax for the payload. This is the syntax that was chosen. > If you already have a SIP parser, then it should be easy to write a > parser for this too. If *you* were defining the event package then you > might make a different choice. > > If you are asking why not just use these as SIP headers in the NOTIFY, > then the answer is that they aren't SIP headers, and you could never > get them approved as such. No, but if you're going off script (that is, off spec) anyway, surely some custom X- headers in the reply would have made life simpler. I agree that this is a splitting-hairs objection. > That is just the way the event mechanism is defined. It is a > degenerate form of a subscription with a longer expiration, and hence > follows all the same rules. Defining different rules would have just > make implementations more difficult. Most standard subscriptions for ordinary presence-type applications seem to generate an immediate NOTIFY with a current state. I'm not sure if this is required by the standard offhand. One could argue that such a NOTIFY in this scenario represents fulfilment of that very case, I suppose. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying
Hello, I apologise for cross-posting this from VoiceOps, and concede that it is an applied and operational question as much as it is a formal one. Nevertheless, any help would be appreciated. As far as I know, SIP redirects are the generally accepted transport for generic data queries (e.g. LRN dips, CNAM) over SIP. However, there is another method, which is used by Metaswitch, Sansay, and possibly some other softswitch vendors: the SUBSCRIBE-NOTIFY method. This is one in which an ephemeral presence subscription (i.e. with an Expires: value of 0) is created by the querying switch, and the CNAM gateway returns a NOTIFY some time later containing the CNAM data reply some time later in its body. The most complete explanation, including some limited insight into design rationales, is available from Neustar, who offer this query method: https://www.neustar.biz/resources/cnam/data-services-lidb-user-guide.pdf See Chapter 7 - IP-CNAM Speification (page 25). This is a weird and, in my opinion, ill-conceived mechanism[1][2]. Nevertheless, it is widely implemented. What I can't seem to figure out is where the formal definition of the standard comes from. It's certainly not an IETF RFC. The Metaswitch CFS provides a hint: MetaSphere CFS and Metaswitch MGC support performing Caller Name Database (CNAM) lookups by sending SUBSCRIBE messages to a database server, and receiving NOTIFYs containing the caller name. The specification of this interface is non-Metaswitch proprietary information. However, example message flows are shown in A.4.16. Whose proprietary information? I found this Verizon patent: https://www.google.com/patents/US20080240383 But it appears to be concerned with an adaptation layer of this to the ISCP side, though I only skimmed it. And if this is the patent in question, why don't any footnotes in vendor docs refer to it? The footnotes cite the SIP event pub-sub framework (RFC 3265) and little else. What the heck is it? And why did it get to be preferred over redirects for some vendors, especially given that it invokes — but ultimately foregoes — most of the bureaucracy of the event subscription mechanism, in a way that's seemingly contradictory. -- Alex [1] For one, it uses attributes in the encapsulated payload which look like headers, but aren't headers: Calling-Name-Status: available Calling-Name: “Joe Smith” <sip:9726840...@cnam-subscriber.com;user=phone> Presentation-Indicator: allowed Why bother with an encapsulated body, then? [2] More objectively, a SUBSCRIBE creates a dialog. But if the lifetime of the subscription is zero (expires immediately), presumably the dialog it creates also ends immediately. Why, then, does the NOTIFY have to be structured as an in-dialog NOTIFY (i.e. same From/To tags as the SUBSCRIBE)? -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] No ACK for 200 OK
Hello, On Mon, Aug 07, 2017 at 04:52:23PM -0700, NK wrote: > 1) Is that really mandatory to send ACK for 200 OK to start the call? > Because once my switch sent the 200 OK then logically the billing is > started from my end, doesn't matter whether I received ACK or not? Without an end-to-end ACK from the caller, it will be terminated after 64*T1 seconds by the callee (as a practical matter, 32 seconds in most implementations). So, yes, sending the end-to-end ACK to fully confirm the session is mandatory. > 2) Even though if my understanding is not correct on point 1, but then > client UA replied to BYE message immediately then how my switch will > treat this, is that treat this as a connected call with duration? How this should be treated from a billing perspective is a matter of some philosophical debate. The call is answered with the 2xx reply, and two-way media flows are possible henceforth, so my inclination is to say that yes, this is a connected call with billable duration. > 3) Do we have any document, I did research but cannot find any clear > document who can state this along with 5407 etc. Not sure what you are referring to here, but RFC 3261 § 13.2.2.4 is quite clear on this subject: The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Semantics of parameters in URI username
Brett, Thank you for your answer, but it is still rather clear—likely to my feeble intellect—how to apply this to my question about use of Diversion to pass state. On 11/04/2016 07:04 AM, Brett Tate wrote: As far as I can tell from the RFC 3261 ABNF, it is permitted to put SEMI and EQUAL in the username of a URI, but it has no semantic validity. The user-parameter can help. However, be aware that some vendors add "user=phone" when user portion is absent or otherwise cannot be decoded as telephone-subscriber. RFC 3261 section 19.1.1: "If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it." Concerning your RFC 4694 example, see RFC 3261 section 19.1.6 concerning how to convert a tel URL into SIP URI. So, how does that work? Is the voodoo that gives username-embedded parameters meaning embedded somehow in the complex rules governing the conversion of 'tel:' scheme URIs to 'sip:'? Or am I mistaken in my assumption that parameters cannot be embedded in the user part of a URI to begin with? The "user=phone" can be added to avoid the ambiguity. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Semantics of parameters in URI username
Hi, As far as I can tell from the RFC 3261 ABNF, it is permitted to put SEMI and EQUAL in the username of a URI, but it has no semantic validity. That is to say, this is permitted:
Re: [Sip-implementors] Arbitrary Via parameters
On 09/30/2016 03:52 PM, Roman Shpount wrote: As far as Via is concerned, the better and standard compliant practice is to encode any application specific data in VIA tag parameter using some sort of proprietary encryption scheme. It is guaranteed that Via tag will be returned to the proxy unmodified. That might conflict with the requirement that the branch parameter be a GUID. It's less important for transaction-identifying GUIDs than for something like Call-ID, but still. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Arbitrary Via parameters
Right on. Well, I don't need the UAS to understand or do anything with the proxy's proprietary parameter. I just need it to behave as it normally would, returning the Via header in responses as-is, together with any proprietary parameters. What it's doing instead is sending replies to the proxy without the proxy's Via at all. This leads the proxy to choke on the response and retransmit ad 64*T1num. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Arbitrary Via parameters
Aah. That makes sense. On September 30, 2016 2:34:29 PM EDT, Roman Shpount <ro...@telurix.com> wrote: >On Fri, Sep 30, 2016 at 2:28 PM, Alex Balashov ><abalas...@evaristesys.com> >wrote: > >> Yeah, but as I understand it, the spec is more explicit on arbitrary >> parameters in the Route set than in Via. >> >> Route is where I'd expect the state to go in this case, too—it's >where all >> other state goes. But the implementors went with custom Via >parameters >> instead. > > >The issue is that responses to SIP request (especially error responses >to >the dialog creating INVITE) do not always contain Route or Record-Route >headers. The only way to store application specific data which is >needed to >forward such SIP responses is in the Via generic parameter. > >Regards, >_ >Roman Shpount -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com) Sent from my Google Nexus. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Arbitrary Via parameters
On 09/30/2016 02:03 PM, Paul Kyzivat wrote: OTOH, if you are *receiving* a SIP message and encounter via parameters that you don't understand, because they aren't defined in the specs you claim to support, then you are expected to ignore them. When forwarding a message that you received, you are expected to pass those parameters along even though you didn't understand them. Thanks, that's what I was looking for. And that's what this UA is not doing. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Arbitrary Via parameters
Yeah, but as I understand it, the spec is more explicit on arbitrary parameters in the Route set than in Via. Route is where I'd expect the state to go in this case, too—it's where all other state goes. But the implementors went with custom Via parameters instead. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Arbitrary Via parameters
PS. 'rport' would seem to provide strong evidence for the idea that arbitrary parameters are supported. But 'rport' is defined in RFC 3581. My question is specifically about arbitrary parameters that aren't defined anywhere. Are implementations required to ignore and conserve them? -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Arbitrary Via parameters
Hi, I have a proxy implementation that adds a custom parameter to Via that is not within the commonly seen subset of "maddr", "ttl", "received", or "branch". It adds a parameter called "i", whose value is alphanumeric (think hex nibbles). I can't find any prose in RFC 3261 to explicitly support the idea that arbitrary parameters are acceptable, but the ABNF appears to allow for it: Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params= via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = "ttl" EQUAL ttl via-maddr = "maddr" EQUAL host via-received = "received" EQUAL (IPv4address / IPv6address) via-branch= "branch" EQUAL token via-extension = generic-param generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string Moreover, RFC 3261 § 20.42 does say: A Via header field value can also contain parameters such as "maddr", "ttl", "received", and "branch", whose meaning and use are described in other sections. In my reading of this, the turn of phrase "such as" is chosen very deliberately. But I could be wrong. So, the question is, would something like 'i=d3adb33f' be acceptable for a proxy to stamp on its own Via header? It sounds like it should be. Yet, I'm dealing with a UAS that doesn't like it—more specifically, it fails to parse the Via if it contains an alphanumeric value, although it copes fine with a strictly numeric one. The result is that responses from the UAS don't contain the proxy's Via header, leading it to barf on processing them. Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Use of "lr" param with a value?
Robert, Thank you very much for the insights! Based on what you and others have said, it stands to reason that there is no justification for sending ;lr=val in 2016. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Sequential requests that bypass RR proxy
Ankur, On 02/10/2016 02:01 AM, ankur bansal wrote: UA will accept it if dialog params matches and its an in dialog request .Both UA have their own view of dialog information which should be same ideally but its not checked if request received is from same UAS/proxy (as per route set stored in dialog ). Well, it's precisely about this gap between ideal and actual implementations that I sought standards-based clarification. Also tell me one thing when BYE received at UE A ,does it have Route header in it ? It does indeed. And given that this is the case, it is all the more peculiar that the UA processes the BYE normally. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Sequential requests that bypass RR proxy
Thanks, Paul. FWIW, B is strictly a UA, not a part-time proxy. The implementors of A have traced the problem to P's attachment of a value to the ;lr parameter in the RR: Record-Route: <sip:xxx.xxx.xxx.xxx:5060;lr=on> They say that's the cause of the breakage. This view is certainly supported by RFC 3261; its grammar clearly states that this is a value-less parameter. However--and I'm sure this has been beaten to death over the years--there are some broken UAs out there that actually _do_ expect an lr= value, to such an extent that Kamailio/OpenSIPS (P is Kamailio in this case) provide a configuration directive to enable the assignment of an lr parameter value in inserted RR headers: http://kamailio.org/docs/modules/4.3.x/modules/rr.html#idm20528 Our implementation of P had this enabled. Seems one can't win. There's got to be a reason this option came about. However, it's been around for a long time, and may date back to the mid 2000s... Any empirical knowledge of whether there remain UAs out there nowadays that don't properly support bareword 'lr'? -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Use of "lr" param with a value?
Fair enough. But it seems a bit schizophrenic of this particular implementation to apply the 'lr" grammar strictly, but then consume the route set anyway (as indicated by improper inclusion of Route headers from B in the BYE), albeit not actually follow it properly. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Use of "lr" param with a value?
From a methodological point of view, I am curious: If the 'lr' parameter has a value assignment, is UA B truly justified in ignoring the route set categorically? Or is that one of those things where behaviour for improperly formed tokens is undefined? -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Use of "lr" param with a value?
On 02/10/2016 02:21 PM, Paul Kyzivat wrote: Charitably, it may have been an attempt to apply Postel's Maxim, but maybe in an inconsistent way at two different points in the code. It seems to me to be a very wanting attempt to apply the Maxim, but this is where my experience with the methodological guidance side of the standards world falls short. So, perhaps it's a bit pedestrian a point of view, but, as I see it: - If one is to be strict in what one accepts, one must be consistently so, not selectively. - If critical validation on RR URI parameters is performed and a parameter is found to be invalid, the response should be explicit, e.g. a rejection with of 400 Bad Request. UA B did not do this. - But if validation is implicit, an RR header perceived to be malformed should be silently discarded, not consumed and integrated into the route set for the dialog. UA B sent the Route header (constructed from the RR) in its BYE to the calling party. If the RR header was malformed, why was it ingested and utilised? All this to say: if the stack is to be strict, be explicitly restrict, but if not, then be consistently strict in every aspect of the same fundamental issue, not merely some aspects, and if one is not going to do be consistently strict, then do not behave in deleterious or unwholesome ways. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Sequential requests that bypass RR proxy
And yes, I realise that from the vantage point of the BYE request, B is the UAC and A is the UAS. That was a poor choice of labelling on my part. On 02/09/2016 08:58 PM, Alex Balashov wrote: Hi, 1. I set up a call between two UAs through a proxy: UAC A > Proxy P1 -> UAS B 2. P1 inserts a Record-Route header indicating that sequential requests should be directed through it. 3. UAS B does not follow Record-Route properly and, upon hanging up, sends a BYE directly to UAC A's Contact URI (remote target), not to P1. Interestingly enough, this BYE includes the Route set constructed from the intervening Record-Route headers, but the BYE is sent to UAC A's Contact directly on the network and transport layer. 4. Clearly, UAS B behaving improperly, but in all known cases, over a variety of UA implementations, UAC A accepts this BYE and the endpoints end the dialog properly -- all unbeknownst to P1. My reading of RFC 3261 doesn't give me clarity as to whether it is proper for a UA to accept a sequential request that otherwise matches a known dialog but which does not originate from an intermediate proxy known by the UA to be in the route set for the dialog. Assuming no properties of firewall or network preclude doing an end-run around the proxy, is this legal? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Sequential requests that bypass RR proxy
Hi, 1. I set up a call between two UAs through a proxy: UAC A > Proxy P1 -> UAS B 2. P1 inserts a Record-Route header indicating that sequential requests should be directed through it. 3. UAS B does not follow Record-Route properly and, upon hanging up, sends a BYE directly to UAC A's Contact URI (remote target), not to P1. Interestingly enough, this BYE includes the Route set constructed from the intervening Record-Route headers, but the BYE is sent to UAC A's Contact directly on the network and transport layer. 4. Clearly, UAS B behaving improperly, but in all known cases, over a variety of UA implementations, UAC A accepts this BYE and the endpoints end the dialog properly -- all unbeknownst to P1. My reading of RFC 3261 doesn't give me clarity as to whether it is proper for a UA to accept a sequential request that otherwise matches a known dialog but which does not originate from an intermediate proxy known by the UA to be in the route set for the dialog. Assuming no properties of firewall or network preclude doing an end-run around the proxy, is this legal? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] sip trunking question
On 07/22/2015 04:23 PM, Paul Heitkemper wrote: I hope this is apropos for this listserv. Is there a good source somewhere which describes (with examples) the messaging inherent in making a trunk? What does it mean to be a trunk? SIP trunking is, to borrow a phrase from Patai Koertge, an accordion concept: when it's expanded and contracted, much marketing music comes out. Trunking is not an especially intelligible concept outside the circuit-switched world. About the only common--but by no means essential or universal!--features of a SIP trunk are: - Policy permits passing calling and called party identity freely. - Designed as an inter-machine peering arrangement, i.e. based on IP trust between industrial network elements that don't necessarily support digest challenge authentication. - Typically end-to-end, without NAT interceding. That said, there are plenty of retail SIP trunking providers for whose offerings none of these things are true. Bottom line: it's little more than a marketing concept designed to make SIP access products understandable to traditional telephony folks, having no basis whatsoever in SIP semantics. It's rather akin to how mid-2000s WiMax providers used to market wireless DSL. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] URI value mandatory for Alert-Info?
Hello, The ABNF grammar for Alert-Info is: Alert-Info = Alert-Info HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) I have an application that seems to utilise just a generic-param without a URI. However, I don't see any */? quantifiers for absoluteURI which suggest that it's optional: absoluteURI= scheme : ( hier-part / opaque-part ) Maybe it's a failure on my part to properly understand ABNF, however. My fundamental question is: is there any grammatically acceptable way to have an Alert-Info header value consisting of no URI and just a generic-param, e.g. Alert-Info: ;internal=xyz Alert-Info: ;internal=xyz Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Unregistering contact bindings
Hello, When a UAC requests to expire a contact binding from a registrar immediately, I have seen both of these formulations: REGISTER sip:domain SIP/2.0 ... To: sip:aor ... Contact: sip:user@nlri;expires=0 and: REGISTER sip:domain SIP/2.0 ... To: sip:aor ... Contact: sip:user@nlri Expires: 0 Which is correct? Are they both admissible? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] [SOLVED] Unregistering contact bindings
Never mind, I should RTFM and Google: http://www.ietf.org/mail-archive/web/sip/current/msg26521.html Thanks, -- Alex On 02/28/2015 01:29 PM, Alex Balashov wrote: Hello, When a UAC requests to expire a contact binding from a registrar immediately, I have seen both of these formulations: REGISTER sip:domain SIP/2.0 ... To: sip:aor ... Contact: sip:user@nlri;expires=0 and: REGISTER sip:domain SIP/2.0 ... To: sip:aor ... Contact: sip:user@nlri Expires: 0 Which is correct? Are they both admissible? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER method is dialog oriented?
No, REGISTER flows do not create dialogs. On 06/03/2014 02:49 AM, Manu Gowdru wrote: Hi All, As we know a dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. 1.Dialog is identified with combination of TO,FROM tag and call-id, REGISTER method also contains TO,FROM tag and call-id so can we consider it as a dialog ID for REGISTER method? 2.Is REGISTER method is a dialog oriented? -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER message without Contact Header and Expires 0
On 05/08/2013 10:21 AM, brezden wrote: On 08/05/13 15:13, Keerthi Srinivasan wrote: Registrar receives the REGISTER request with no contact header and expires header with 0. what registrar has to do? it has to fetch all the binding for the AOR or deregister binding? can any help me? From RFC3261, Section 10.2 Constructing the REGISTER Request The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included... I think the OP was asking what the implications of a Contact-less REGISTER request actually are. Does it have a no-op effect? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER message without Contact Header and Expires 0
On 05/08/2013 10:23 AM, Uttam Sarkar (usarkar) wrote: It's a deregister request. So you need to remove all the bindings for that AoR. That's what I thought. Thanks Uttam! -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] plz solve my problem
Ah, satya r, the gift that keeps on giving. You formulate your questions in a manner that suggests that you yourself do not care about the answer, nor are encountering a problem to which the answers to those questions represent a practical solution. This is SIP-Implementors, not SIP-Homework-Help. -- Alex On 03/14/2013 01:04 AM, satya r wrote: plz give me a scenario of 1.call transfer 2. call forward 3.call park its very urgent for me plz solve it Regards Satya ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] npdi parameter in sip: scheme URIs
Between RFC 3398 and 4694, I am unclear on whether the 'npdi' parameter can only appear in the user part of a sip: RURI: sip:5551212;rn=...;npdi@domain:5060 or whether it can also appear in the domain part: sip:5551212@domain:5060;rn=...;npdi All I can find are references to the idea that these parameters appear within the Request URI. Are both cases valid? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] npdi parameter in sip: scheme URIs
On 04/11/2012 11:18 AM, Paul Kyzivat wrote: npdi is defined as a tel uri parameter, not as a sip uri parameter. It makes its way into a sip uri based on the embedding of the body of a tel uri into a sip uri. This results in the parameter appearing in the user part of the sip uri, as in your first example. That was very much my belief as well -- thanks for confirming it. Just saw an INVITE from a Sansay with a ;npdi in the domain, and did a double-take, but was unable to parse through the supporting references. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] npdi parameter in sip: scheme URIs
Hmm. I wonder if this has to do with whether one is using npdi in a tel URI mapping or a SIP-ISUP mapping context. On 04/11/2012 11:49 AM, Alok 2 Tiwari wrote: Hi Alex, npdi is a parameter in Request URI. So it neither can appear in the user part nor in the domain part. It will appear as a uri-parameter as per following grammar. Request-Line= Method SP Request-URI SP SIP-Version CRLF Request-URI = SIP-URI / SIPS-URI / absoluteURI SIP-URI = sip: [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI= sips: [ userinfo ] hostport uri-parameters [ headers ] uri-parameters = *( ; uri-parameter ) uri-parameter =transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / compression-param / target-param / cause-param / orig / gr-param / other-param as per above grammar, following is valid example. sip:5551212@domain:5060;rn=...;npdi Regards, Alok Tiwari Aricent From: sip-implementors-boun...@lists.cs.columbia.edu [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Alex Balashov [abalas...@evaristesys.com] Sent: Wednesday, April 11, 2012 8:07 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] npdi parameter in sip: scheme URIs Between RFC 3398 and 4694, I am unclear on whether the 'npdi' parameter can only appear in the user part of a sip: RURI: sip:5551212;rn=...;npdi@domain:5060 or whether it can also appear in the domain part: sip:5551212@domain:5060;rn=...;npdi All I can find are references to the idea that these parameters appear within the Request URI. Are both cases valid? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Route-Record
Is your concern about the two RR headers, or the double lr parameter? -- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness. Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Dec 21, 2011, at 1:03 AM, William Scott will...@magicwilly.info wrote: Hi, I have a ATA that produces... Record-Route: sip:202.85.243.105;lr;lr Record-Route: sip:202.85.243.105:5070;lr;lr in the 200 OK reply to an INVITE. Good, bad or doesn't matter? ___ 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] Is it valid/legal to IPv4 control channel and IPv6 data channel?
Curious, why not? In principle, if the endpoints support IPv6 for media, why can't that be described in an SDP body transmitted over IPv4? Is it not the very purpose of the separation of the signaling and bearer plane to be able to enact this kind of functional decomposition between signaling agents and media gateways? -- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness. Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Nov 22, 2011, at 4:25 AM, Brez Borland brez...@gmail.com wrote: Hi Michael, SIP is signalling, and SDP describes the media session. These are two separate channels. I can't see SIP being done through IPv4 and media session over IPv6 to be a problem. This is theory. But can anybody comment from their experience? Regards, Brez On Mon, Nov 21, 2011 at 5:06 PM, Michael Lui (milui) mi...@cisco.comwrote: Hi experts, Is it valid/legal to IPv4 control channel and IPv6 data channel? For example, the INVITE exchange is in IPv4 but the IP addresses specified in SDP is IPv6. I don't think this is common but If allow, what is the practical scenario? Thanks, Michael ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is it valid/legal to IPv4 control channel and IPv6 data channel?
I'm sorry; I think my response took the wrong tone. It was meant to be rhetorical, and principally in response to the initial query. I apologise for the misunderstanding. -- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness. Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Nov 22, 2011, at 5:27 AM, Brez Borland brez...@gmail.com wrote: Hi Alex, But that's what I said, these are two separate channels and can be done over IPv4 and IPv6. Regards, Brez On Tue, Nov 22, 2011 at 9:47 AM, Alex Balashov abalas...@evaristesys.com wrote: Curious, why not? In principle, if the endpoints support IPv6 for media, why can't that be described in an SDP body transmitted over IPv4? Is it not the very purpose of the separation of the signaling and bearer plane to be able to enact this kind of functional decomposition between signaling agents and media gateways? -- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness. Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Nov 22, 2011, at 4:25 AM, Brez Borland brez...@gmail.com wrote: Hi Michael, SIP is signalling, and SDP describes the media session. These are two separate channels. I can't see SIP being done through IPv4 and media session over IPv6 to be a problem. This is theory. But can anybody comment from their experience? Regards, Brez On Mon, Nov 21, 2011 at 5:06 PM, Michael Lui (milui) mi...@cisco.comwrote: Hi experts, Is it valid/legal to IPv4 control channel and IPv6 data channel? For example, the INVITE exchange is in IPv4 but the IP addresses specified in SDP is IPv6. I don't think this is common but If allow, what is the practical scenario? Thanks, Michael ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] B2BUA
On 07/28/2011 05:14 AM, Couret Tabt wrote: If we want to avoid those retransmissions of 200 OK, then what should we do? Reduce end-to-end latency? -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] How may SIP systems adopt 'B2BUA' ?
The term SIP system is ambiguous to the point of meaninglessness? There are many types of SIP endpoints and network elements. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] 100rel without direct reachability
Greetings, I have a scenario where endpoint A is calling endpoint B through proxy P. Endpoints A and B are on different networks that are not directly reachable--A is on the public Internet, to which proxy P is connected, but NAT'd, and B is on a private RFC1918 network on which the proxy P has an interface as well. The purpose of proxy P is to make calling A - B possible, while providing the appropriate far-end NAT traversal functionality for A and so on and so on. It does this by inserting the correct Record-Route headers into the INVITE from A, and otherwise by staying in the signaling path; both A and B can reach the proxy, so all requests and replies go through it. The problem I'm having is prior to full dialog establishment. Upon receipt of INVITE from A by way of proxy P, B replies with 183 + SDP and also: Require: 100rel In the 183 it provides a Contact on its private network that A obviously cannot reach: Contact: sip:x@192.168.0.10:5060 As a result, A attempts to send PRACKs to sip:x@192.168.0.10, which are obviously not going to go anywhere. After not receiving a few of these expected PRACKs, B replies to the call with a final negative failure. The question is, is there anything I can twiddle on the proxy to make this work? The problem with PRACKs is that although they are sequential requests, they arise (in this case) prior to the point at which RR can be used to guide them through the proxy. The most obvious answer is, Make B not Require: 100rel, of course. However, that is not an option here. Thanks! -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 100rel without direct reachability
On 06/18/2011 05:03 PM, Alex Balashov wrote: Greetings, I have a scenario where endpoint A is calling endpoint B through proxy P. Endpoints A and B are on different networks that are not directly reachable--A is on the public Internet, to which proxy P is connected, but NAT'd, and B is on a private RFC1918 network on which the proxy P has an interface as well. The purpose of proxy P is to make calling A- B possible, while providing the appropriate far-end NAT traversal functionality for A and so on and so on. It does this by inserting the correct Record-Route headers into the INVITE from A, and otherwise by staying in the signaling path; both A and B can reach the proxy, so all requests and replies go through it. The problem I'm having is prior to full dialog establishment. Upon receipt of INVITE from A by way of proxy P, B replies with 183 + SDP and also: Require: 100rel In the 183 it provides a Contact on its private network that A obviously cannot reach: Contact:sip:x@192.168.0.10:5060 As a result, A attempts to send PRACKs to sip:x@192.168.0.10, which are obviously not going to go anywhere. After not receiving a few of these expected PRACKs, B replies to the call with a final negative failure. The question is, is there anything I can twiddle on the proxy to make this work? The problem with PRACKs is that although they are sequential requests, they arise (in this case) prior to the point at which RR can be used to guide them through the proxy. The most obvious answer is, Make B not Require: 100rel, of course. However, that is not an option here. The basic problem here seems to be that B is not copying the RR headers into the 183 responses it is sending. And according to 3261, it doesn't have to. 3262, however, which defines 100rel, has a table on page 7 suggesting that Record-Route headers go into 18x,2xx responses. Am I correct in presuming that the table in 3262 constitutes a kind of amendment to the 3261 stance, and that this is a UAS bug on B? I've worked around it by manually adding the RR header to the reply, and the PRACKs are now targeted correctly. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] How to avoid hard coding of IP Address?
The answer is to learn C (or whichever C-derived language you are using to implement), most especially including its standard library and its associated string functions, as well as system calls. There are a variety of ways to pass data into your program, such as command-line arguments, environment variables, and, of course, reading from configuration files. On 04/18/2011 03:44 AM, Siga wrote: Hi, I need some information of how can I avoid the hard coding of the IP Address in my implementation, right now I am using socket programming for my SIP implementation and I am hard coding the IP Address in my code for example local.sin_addr.s_addr = 1.2.3.4; . One more question is, in the SIP session is it also possible to eliminate the hard coding of IP Address especially in SIP INVITE, ACK, BYE and so on. Because with this I can only connect to one remote host and every time I want to connect to another remote host I needed to do some changes in my code. Any good information with an example or any useful links to overcome this problem will be really useful. Regards ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Invitation to connect on LinkedIn
We are, perhaps, forever doomed to a blighted, Sisyphean existence, falling just short of grasping the proper use of mailing lists, contact managers/address books, and other basic computer skills. We reach for the stars, but all we can do is extend our arms in vain, pitiable aspiration. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Apr 10, 2011, at 1:53 AM, Imran Saleem via LinkedIn mem...@linkedin.com wrote: LinkedIn Imran Saleem requested to add you as a connection on LinkedIn: -- Priyank, I'd like to add you to my professional network on LinkedIn. - Imran Accept invitation from Imran Saleem http://www.linkedin.com/e/-ftd1dd-gmbk542l-2z/cFM0GAd-yBCwaJGWsQs1GGTyK-p78Ke3DbMDt3xi3HiTZiXE_HRum-ba/blk/I124499944_20/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYMcBYQd3AVejgQcz59bPtUlQRikz1IbPkMcjgTd3oSdz8LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Imran Saleem http://www.linkedin.com/e/-ftd1dd-gmbk542l-2z/cFM0GAd-yBCwaJGWsQs1GGTyK-p78Ke3DbMDt3xi3HiTZiXE_HRum-ba/blk/I124499944_20/30OnPgQejAVd3gOckALqnpPbOYWrSlI/svi/ -- DID YOU KNOW you can conduct a more credible and powerful reference check using LinkedIn? Enter the company name and years of employment or the prospective employee to find their colleagues that are also in your network. This provides you with a more balanced set of feedback to evaluate that new hire. http://www.linkedin.com/e/-ftd1dd-gmbk542l-2z/rsr/inv-27/ -- (c) 2011, LinkedIn Corporation ___ 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] SIP Server
Evgeniy, Its stock config file has come a long way in accomodating most commonsensical needs. -- Alex -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Mar 2, 2011, at 12:35 AM, Evgeniy Khramtsov xramt...@gmail.com wrote: 02.03.2011 03:39, Daniel-Constantin Mierla wrote: Hello, On 3/1/11 5:18 PM, Siga wrote: Hi, I need to test my SIP Client, can somebody recommend me which SIP Server is good and easy to set up and can be used to test my SIP Client, especially I need it for testing sending and receiving data packets from my Client you can use Kamailio, which is open source and free. Kamailio is easy to set up? Is it a joke? :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru. ___ 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] SIP Soft Phone with IPSec Support
On 01/05/2011 03:26 PM, Olle E. Johansson wrote: Someone else can propably describe this is in a better way, but a softphone could potentially handle this. It would be pretty clever and avoid all the issues with TLS and SRTP... It seems a little impractical, but consistent with IMS's loftily bureaucratic style. From a concrete, implementational point of view, TLS, or a lower-layer encrypted tunnel/transport would be a lot easier, at least if I'm reading this RFC3329 correctly. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Soft Phone with IPSec Support
That's like asking if there is a SIP softphone that supports Ethernet. Go learn your OSI burrito. IPSec operates at a different layer of abstraction in the protocol stack than a VoIP application. It would not be IPSec-aware if used with IPSec. In that sense, all softphones support IPSec. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Jan 4, 2011, at 9:27 PM, Bharat S bharat.sar...@yahoo.com wrote: Hi all, Does any body know about SIP Soft Phone that supports IPSec? Thanks, Bharat ___ 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] SIP Soft Phone with IPSec Support
On 01/04/2011 09:52 PM, Bharat S wrote: Hey Alex, I know IPSec operates on different layers of protocol stack. But I am looking for any SIP soft phone that supports Headers for SIP Security. RFC 3329. So if any phone supports IPSec, should support the SIP Headers required for establishing Security Associations using IPSec. I hope you got my question. Really? They actually have an IPSec security method for SIP? Well then, I stand corrected. Serious egg on my face. Here I was thinking the term IPSec only refers to a lower-level encapsulation. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] CENTREX Solution with SIP
On 11/29/2010 10:44 AM, Ali Kemal MAYUK wrote: I am investigating about how Centrex work with SIP. If an enterprise customer has a 2 different locations, how they call each other with short numbers(4 digit) ? Which SIP headers are used for it? Is there a standartization ? Does any one have a solution documentation? How the big companies handle it? This is not a question about SIP protocol mechanics or implementation, although you may not know that. Your question is about an abstraction of SIP endpoint behaviour (initiating calls between two or more endpoints) to serve the needs of a high-level application and/or marketable product. There is nothing special whatsoever about how Centrex-like products are implemented using SIP endpoints, nor any specific accommodation for this kind of functionality within the protocol. Your real question is, How do I dial between SIP endpoints using arbitrary routing designations? The answer is: the same way you'd dial in any other scenario. As usual, the dialed digits are present in the Request URI and (usually) the To header. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street NE 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error response for OA failure
It depends on the type of body, and therefore on whether a body in the final reply is also required. If the body in question is SDP, I would say 488 Not Acceptable Here, because the answer (or the lack of one) is not compatible with the offer. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Nov 23, 2010, at 5:44 PM, Nauman Sulaiman nauman762- h...@yahoo.co.uk wrote: Hi, For a Re-invite scenario If the OA process fails due to example a UAS sending a 200OK without a body to an INVITE with a body from UAC. What is the correct response of the UAC? Thanks ___ 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] Don't Proxy Authenticate check 'From' for 'username'?
The user part of the From URI should be checked for consistency with digest authentication username, or other security policy. Otherwise, you are quite correct. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Nov 7, 2010, at 3:33 AM, Couret Tabt courett...@gmail.com wrote: Dear folks, I am designing new secure SIP communication. So, I have a question. In authentication of Proxy Authenticate, isn't 'From' address checked for 'username'? In other words, even if user write wrong 'From' address, when right username is given, then can this message pass the Proxy Authenticate? Accordingly, can user do spoofing atacks? If you know, please let me know. Kinds, Tabt. ___ 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 Offer ANswer
. ___ 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 -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Stacks
On 10/12/2010 12:15 PM, Iñaki Baz Castillo wrote: Second paragraph of Section 18.1.1 of RFC 3261: - If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. - IMHO this is an exotic specification. What about if the proxy/registart has to route a long request to a user registered in a UDP location? should the proxy try TCP? to which port? what about NAT? So this is a so exotic feature that I strongly understand everybody ignores it [*]. Strongly agreed. This is one of the most batshit inane, idiotic requirements I have ever seen, and it should be rightly ignored by everyone in light of the realities of today's Internet. UDP is designed to be able to transport up to 65535 bytes of payload, and that is what a protocol using UDP as a transport should allow. All SIP UDP endpoints and ALGs should support IP/UDP reassembly, without question. Mandating use of TCP in this situation is simply not realistic, especially when so many otherwise mainstream and well-heeled, stable SIP stacks don't support it (for example, Asterisk, many softphones, etc.). -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Detection of Cable disconnections in SIP
On 10/06/2010 01:52 AM, Manoj Priyankara [TG] wrote: If there's a LAN cable disconnect during a SIP session that is during a call how does the other party recognize it? As an example, let us consider UA A and UA B are in a call. Suddenly UA A disconnects. How does the UA B know A is no longer connected? There's no such mechanism that inheres in basic 3261 SIP per se. A common feature of endpoints that also receive media is to time out calls after no RTP has been received for a certain number of seconds. A purely SIP solution is to use session timers, but not all endpoints support them; take a look at RFC 4028. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Detection of Cable disconnections in SIP
On 10/06/2010 02:35 AM, $...@r\/|r!`/@ wrote: To add to Alex answer, RFC 4028 suggest a solution by which if your UA supports the RFC then timeouts can be managed. Thus even if another NE do not support it and your UA does, you will be able to detect any broken connection. Yep. But at least one endpoint must have Supported: timer -- Alex -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Detection of Cable disconnections in SIP
It really sounds like session timers (RFC 4028) are your best bet. On 10/07/2010 12:33 AM, $...@r\/|r!`/@ wrote: Hi, Its not always a voice callin video calls we would need such mechanism. cheers!! sarvpriya On Wed, Oct 6, 2010 at 7:27 PM, Worley, Dale R (Dale)dwor...@avaya.comwrote: From: sip-implementors-boun...@lists.cs.columbia.edu [ sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Manoj Priyankara [TG] [mano...@suntel.lk] If there's a LAN cable disconnect during a SIP session that is during a call how does the other party recognize it? As an example, let us consider UA A and UA B are in a call. Suddenly UA A disconnects. How does the UA B know A is no longer connected? ___ Hello? [pause] Hello?? [pause] HELLO!!! [pause] [user hangs up] [UA sends BYE, receives no response, clears dialog state] Seriously, that is how UAs are expected to clear calls whose IP connectivity has been lost. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] What is the practical benefit of hop-by-hop methods?
Hi Robert, On 09/13/2010 07:19 PM, Robert Hoffmann wrote: Hi there, a) I am not sure about what the practical benefit of hop-by-hop methods like CANCEL or ACK (for 3XX-6XX responses) is. b) Also, why is 100 Trying a hop-by-hop response? Would it hurt to have it being end-to-end? c) Why don't we have end-to-end messages only? It seems to me that the logical purpose of hop-by-hop replies or request methods is to elicit acknowledgment or communicate receipt from all network elements in the signaling path, regardless of whether they are proxies or UAs, in situations in which that information is desirable to know from the point of view of semantics and the state machine. So, for example, the standard envisions that it is useful to know that a proxy has itself received and processed a negative reply, even if the issuing UAC has gone away or something like that. Hop-by-hop CANCEL is more or less a mandatory requirement of forking, as you mentioned, since in many cases the proxy is the conceptual target of the CANCEL request because the transaction is being presented to UAC opaquely as a single branch, while there are lots of branches on the other side to the management of which a CANCEL must be applied/translated. The 100 Trying response exists mainly to dampen retransmissions by telling the UAC that the request has been received and is being worked on. Sometimes, there are unpredictable sources of latency that arise at this stage of call setup if a proxy is involved, as, for example, due to: - High database load / response time. - High end-to-end network latency physically. - Additional latency involved in serial forking through successively failing branches (common in wholesale PSTN routing scenarios). Any one of these or other causes can cause Timer T1 to throw before an upstream 100 Trying from a UAS is received and forwarded, and cause undesirable retransmissions or premature failover. So, 100 Trying is a way of telling the UAC, All right, I got your request, now just be patient and wait, because there might be some latent operations involved before I can give you any other provisional or final replies. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Invitation to connect on LinkedIn
Fail. On 09/07/2010 05:31 AM, Romal Patel wrote: LinkedIn Romal Patel requested to add you as a connection on LinkedIn: -- Priyank, I'd like to add you to my professional network on LinkedIn. - Romal Accept invitation from Romal Patel http://www.linkedin.com/e/-ftd1dd-gdsk9hk1-50/cFM0GAd-yBCwaJGWsQs1GGTyK-p78Ke3DbMDt3xi3HiTZiXE_HRum-ba/blk/I8922441_20/6lColZJrmZznQNdhjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0OnP4Qd38Oejx9bSZVhzdRtR1kbPsPczoTdP4Qdz4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Romal Patel http://www.linkedin.com/e/-ftd1dd-gdsk9hk1-50/cFM0GAd-yBCwaJGWsQs1GGTyK-p78Ke3DbMDt3xi3HiTZiXE_HRum-ba/blk/I8922441_20/c39vcjgQcz8Ve4ALqnpPbOYWrSlI/svi/ -- DID YOU KNOW LinkedIn can help you find the right service providers using recommendations from your trusted network? Using LinkedIn Services, you can take the risky guesswork out of selecting service providers by reading the recommendations of credible, trustworthy members of your network. http://www.linkedin.com/e/-ftd1dd-gdsk9hk1-50/svp/inv-25/ -- (c) 2010, LinkedIn Corporation ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 100 trying response
It should be sent immediately. There is no harm in sending such a response immediately. The 200 ms anticipated respose processing time is a guideline for people who can't make up their minds. Due to commonplace variations in end-to-end network delay on the Internet, you should pretty much always send 100 Trying. Going over 200 ms is trivially common even for reasons unrelated to processing. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Aug 22, 2010, at 6:14 AM, mustafa rifaee mustafa.rif...@gmail.com wrote: Hi all; I would like to ask you about 100 Trying for INVITE Request; The RFC 3261 says: A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response IS this mean the Proxy server should send the 100 trying after 200 ms, or the proxy can send it immediately? how the SIP proxy can expects that response can take more than 200 ms? Please Help me; Best Regards Mustafa Rifaee ___ 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] Malformed ACKs/sequential request lines
On 07/30/2010 04:59 AM, WORLEY, Dale R (Dale) wrote: While 3261 systems should interoperate correctly with 2543 systems, 2543 systems are considered obsolete these days. I think the issue is that there is a proxy inserting an RR header with the 'lr' parameter in the middle of the flow. I'm sure if this were a straight UAC-UAS call, they'd interoperate fine. But the proxy is not forwarding this ACK to UAS B. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
