Re: [Sip-implementors] Call hold with a=inactive
No, A is not on hold. Placing on hold requires a user action. Unless the user of A placed it on hold, A is not on hold. Anything done by B doesn't affect A hold status. _ Roman Shpount On Thu, Sep 7, 2023 at 8:38 AM Sundbaum Per-Johan (Telenor Sverige AB) < per-johan.sundb...@telenor.se> wrote: > But you could argue that also A is on hold after “*3. A sends 200 ok > with a=inactive” ?* > > BR/pj > > > > > Sensitivity: Internal > From: Roman Shpount > *Sent:* den 7 september 2023 14:26 > *To:* Sundbaum Per-Johan (Telenor Sverige AB) < > per-johan.sundb...@telenor.se> > *Cc:* sip-implementors@lists.cs.columbia.edu > *Subject:* Re: [Sip-implementors] Call hold with a=inactive > > > > A should respond with a=sendrecv. The A response (offer in 2XX response to > a re-INVITE) should depend on A hold status only. The state of B has no > effect on A offers. So, since A is not on hold, a=sendrecv is the most > appropriate answer. > > > > On the other hand, if A sends a re-INVITE without SDP to B, B should > respond with a=inactive, since B is on hold. > > _ > Roman Shpount > > > > > > On Thu, Sep 7, 2023 at 6:55 AM Sundbaum Per-Johan (Telenor Sverige AB) < > per-johan.sundb...@telenor.se> wrote: > > Hi ! > > A question that I hope is simple for some helpful person to answer: > > 1. Call connected between A and B > 2. B holds the call with re-INVITE a=inactive > 3. A sends 200 ok with a=inactive > 4. B sends re-INVITE without SDP > > A should answer a=sendonly or is a=sendrecv normally a better option or > perhaps something else ? > > > MVH/pj > > > > Sensitivity: Internal > ___ > 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] Call hold with a=inactive
A should respond with a=sendrecv. The A response (offer in 2XX response to a re-INVITE) should depend on A hold status only. The state of B has no effect on A offers. So, since A is not on hold, a=sendrecv is the most appropriate answer. On the other hand, if A sends a re-INVITE without SDP to B, B should respond with a=inactive, since B is on hold. _ Roman Shpount On Thu, Sep 7, 2023 at 6:55 AM Sundbaum Per-Johan (Telenor Sverige AB) < per-johan.sundb...@telenor.se> wrote: > Hi ! > > A question that I hope is simple for some helpful person to answer: > > 1. Call connected between A and B > 2. B holds the call with re-INVITE a=inactive > 3. A sends 200 ok with a=inactive > 4. B sends re-INVITE without SDP > > A should answer a=sendonly or is a=sendrecv normally a better option or > perhaps something else ? > > > MVH/pj > > > > Sensitivity: Internal > ___ > 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] UAC sends ACK using transport UDP instead of TLS as specified in INVITE and Via
The sections you are looking for are https://www.rfc-editor.org/rfc/rfc3261.html#section-13.2.2.4 and https://www.rfc-editor.org/rfc/rfc3261.html#section-12.2.1. ACK for 2XX response is a new request within the dialog. Its destination is independently evaluated based on the route set (Contact and Route headers in 2XX response). If the Contact header for 200 OK response has a sip URI with port 5061 and no transport parameter, then ACK MUST be sent using UDP to port 5061. The original URI for INVITE and VIA headers for 2XX are all irrelevant. Also, please note that "transport=tls" is deprecated (see https://datatracker.ietf.org/doc/html/rfc3261#section-26.2.2). To summarize, you are dealing with a non-compliant or misconfigured provider (using tranport=tls in the INVITE) and the SBC (not providing sips URL in the contact when listening on TLS port only). Best Regards, _____ Roman Shpount On Tue, Aug 29, 2023 at 12:00 PM wrote: > The dilemma I have is a UAC (service provider) sends an INVITE with > transport=tls in the Request header as well as in the Contact header, using > the SIP: URI scheme (not SIPS:). > > > > The UAS (an SBC) responds with a 200 OK, but it's Contact header doesn't > provide a transport parameter, just a SIP: URI with IP and port (5061). > However, the Via: header does reflect TLS (there are no Record-Routes). > > > > The UAC responds with the ACK, but because the transport parameter isn't > listed in the 200 OK Contact header, the UAC sends it UDP instead of TLS. > > > > The UAS then discards this as it's listening only on port 5061 (signaling > port is strictly TLS over TCP, no UDP). > > > > The service provider insists that the Contact header on the SBC's 200 OK > needs to specify transport=tls, and by not specifying it, the SBC changes > the transport mid-dialog, regardless if it has the default port for TLS > 5061, and TLS is specified in Via: header. Thus why they send the ACK UDP > which then isn't received. > > > > This call flow is setup similarly for several other SBC clientele, and this > is the first time ever to have this problem. Others respond with the ACK > using TLS even though transport=tls isn't a parameter in the 200 OK's > Contact header, but does have port 5061 and TLS listed in Via: header. > > > > I've been reading through RFC 3263 as well as 3261 sections 18 & 19, but > I'm > not finding anything definitive that a UAC MUST or SHOULD send the ACK > using > the same transport as INVITE, Via header, or default port when it's not > directly indicated within the SIP reply's Contact header. or that by not > specifying transport=tls in the Contact header on a SIP reply (200 OK), > that > then changes the transport to UDP. > > > > Any suggestions on RFC sections or threads that my provide better clarity > on > this particular dilemma? > > > > ___ > 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] What is the rule for retransmitting the SIP packet
No, they do not. _ Roman Shpount On Mon, Apr 10, 2023 at 12:25 PM 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
Re: [Sip-implementors] What is the rule for retransmitting the SIP packet
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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] How to differentiate Hold RTP and voice RTP
In practice, there is no "typical" way of putting a call on hold. The very meaning of that action is highly dependent on what you are looking at. If you are looking at signaling coming from an IP phone, you seldom get a=sendonly when someone is placing a call on hold. You will only see that when someone is playing music on hold, which is more common for a PBX or CPaaS. IP Phones normally do not play music on hold so you will see an a=inactive or c=IN IP4 0.0.0.0 IP address. With CPaaS or PBX to an IP phone, you will see a=sendonly or a=inactive, depending on if the music on hold is configured. When communicating with a VoIP service provider over s SIP trunks with SBC, it is unlikely you will see any signaling, IP, or SSRC changes when a call is placed on hold. If you are directly dealing with IMS or RCS environments, you will be overwhelmed with wonder when trying to decipher the reasoning behind each signaling scenario. So, YMMV _____ Roman Shpount On Mon, Oct 10, 2022 at 10:17 PM Dale R. Worley wrote: > Ranjit Avasarala writes: > > Another way to check is the SDP. for hold music, the media attribute > will > > be sendonly. where as for regular voice traffic it will sendrecv > > Yes, the "typical" way to tell that the far end has put you on hold is > that they will send you a=sendonly in the SDP. Of course, that isn't > guaranteed to be done, but at least it is what people expect and many > systems conform to that. > > In regard to trying to determine on-hold status from the RTP, that is > not reliable. If you can detect that the far end is sending music, it > has likely put you on-hold. But somtimes there are voice announcements > during on-hold. > > 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
Re: [Sip-implementors] How to differentiate Hold RTP and voice RTP
Arun, Depending on the scenario, nothing will be different. You cannot rely on signaling or SSRC. The calling parting can be behind the PSTN gateway and continue to send audio regardless of the hold state on the origination side. The only way to differentiate is to check the actual audio content. For a generic solution, you need to use a VAD algorithm to differentiate between voice vs. silence vs. hold music. You can look at https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/common_audio/vad/ for reference. _ Roman Shpount On Thu, Sep 22, 2022 at 10:56 AM Arun Tagare wrote: > Thanks Ranjit, > > Yes for the signalling part i am aware, but as shared earlier how the RTP > from N/w and other UE in same session be differentiate? > > So SSRC will be different right? > > On Thu, 22 Sep 2022 at 8:05 PM, Ranjit Avasarala > wrote: > > > Hi Arun > > > > Both are technically voice packets and use RTP protocol. So that way > both > > are similar. Also the voice traffic is end to end whereas hold music is > > from the server. Like announcement - may be from Application Server. So > > looking at the SSRC or Source in RTP Packets, you should be able to say > > which entity is sending those packets. > > > > Another way to check is the SDP. for hold music, the media attribute > > will be sendonly. where as for regular voice traffic it will sendrecv > > > > Regards > > Ranjit > > > > On Thu, Sep 22, 2022 at 4:19 AM Amanpreet Singh < > > amanpreeet.si...@gmail.com> wrote: > > > >> Arun, for what purpose would you like to inspect and differentiate the > >> hold > >> and audio RTP packets? > >> and based on the signaling messages, can't that be achieved. > >> > >> Thanks, > >> Amanpreet Singh. > >> > >> > >> On Thu, Sep 22, 2022 at 12:30 PM Arun Tagare > >> wrote: > >> > >> > Thanks Ranjit & Amanpreet, for your response > >> > > >> > But my question is > >> > > >> > MT <= Call Established ===> MO > >> > MT <===> Voice RTP Packets flow <=> MO > >> > MT <==Hold ===> MO > >> > MT < HOLD Tone RTP packets == NW > >> > > >> > Both Voice RTP packets and Hold RTP packets come to the same port > right > >> ? > >> > How to differentiate these RTP packets > >> > > >> > On Thu, Sep 22, 2022 at 11:06 AM Amanpreet Singh < > >> > amanpreeet.si...@gmail.com> wrote: > >> > > >> >> Probably you can think of looking into the signaling messages(SDP in > >> case > >> >> of SIP) to differentiate when the call is on hold and when not i.e. > >> normal > >> >> audio RTP. > >> >> > >> >> BTW what is the use case to differentiate call hold vs audio RTP? > >> >> > >> >> > >> >> Regards, > >> >> Amanpreet Singh. > >> >> > >> >> > >> >> On Wed, Sep 21, 2022 at 9:51 PM Arun Tagare > >> >> wrote: > >> >> > >> >>> Hi All, > >> >>> > >> >>> I have a doubt on the Hold call tone or music on hold tone RTP v/s > >> actual > >> >>> voice RTP before hold > >> >>> > >> >>> Can these RTP packets be able to differentiate? > >> >>> If yes how? > >> >>> if not why? > >> >>> > >> >>> Thanks a lot to everyone in advance > >> >>> > >> >>> -- > >> >>> > >> >>> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 3261 section 14.2 - "brand new call" does not specify whether the SDP should modify media attributes of an existing session containing a=sendonly or a=recvonly
Shaun, I am the person who actually got the language about handing re-INVITE without SDP into RFC 3261 as "a brand new call". The initial intent was to enable a third party call control to initiate a new call by sending a re-INVITE without SDP to an existing call and then place another call to a new party. If I understand correctly, FreeSwitch is sending a response with "a=recvonly" to a re-INVITE with no SDP? If this is the case, since they are a media server, in this particular situation they are probably wrong, but generally the answer is "it depends". Because of this, you are not going to find an RFC that specifies the one and only correct procedure. The general idea is that sendonly/recvonly in every SDP exchange should reflect the preferences for the user agents, not what was previously negotiated. Imagine that one UA is putting another UA on hold. In this case this phone sends a re-INVITE with a=inactive (or a=sendonly which only makes sense if the UA plans to play the music on hold). The second UA will respond with a=inactive or a=recvonly. If the second UA later sends a re-INVITE without SDP, the first UA will still respond with SDP with a=inactive (or a=sendonly), since it is still on hold. If the UA which is currently on hold sends a re-INVITE with no SDP, then the other UA should respond with a=sendrecv (since it is not on hold), but the first UA should respond with a=inactive (or a=sendonly) in SDP in ACK, since it is still on hold. In other words, re-INVITE does not change the local UA hold status, only a user action does this. Based on the local hold status and the remote direction attribute the UA should respond with an appropriate direction attribute in the answer. If you are using FreeSwitch as a media server, then the local call status is likely not on hold and it should be able to send/recv media, which should be indicated in the response to a re-INVITE with no body. In general case, the local call status is something that depends on the application running on FreeSwitch, which you do not specify. This is why the general answer "it depends". I hope it helps, _ Roman Shpount On Mon, Sep 7, 2020 at 2:11 AM Shaun Stokes wrote: > Hi, > > We've been struggling with some of the interpretation used in RFC 3261 > section 14.2 which has created a conflict between the software we use > (FreeSWITCH) and another environment (based on Cisco previously Broadsoft > equipment) both of which claim to be RFC 3261 compliant and claim that the > other is not. > > The problem occurs when the 3rd party sends an SDP with the media > attribute 'a=sendonly' on an existing session then follow with a RE-INVITE > with-out an SDP, they claim that our 2xx offer in response should contain > an SDP with-out 'a=sendonly' (or replace with 'a=sendrecv') based on the > interpretation of a "brand new call" used below. Anthony Minessale II > (FreeSWITCH lead) claims that "brand new call" is only intended to refer to > codecs (not all media attributes) and that the 3rd party (Broadsoft) > invented this concept on their own. > > RFC 3261 > > 14.2 UAS Behavior > A UAS providing an offer in a 2xx (because the INVITE did not contain > an offer) SHOULD construct the offer as if the UAS were making a > brand new call, subject to the constraints of sending an offer that > updates an existing session, as described in [13] in the case of SDP. > Specifically, this means that it SHOULD include as many media formats > and media types that the UA is willing to support. The UAS MUST > ensure that the session description overlaps with its previous > session description in media formats, transports, or other parameters > that require support from the peer. This is to avoid the need for > the peer to reject the session description. If, however, it is > unacceptable to the UAC, the UAC SHOULD generate an answer with a > valid session description, and then send a BYE to terminate the > session. > > Source: https://tools.ietf.org/html/rfc3261#section-14.2 > > > The 3rd party have also stated that this isn't a call going on hold as > it's routing to an ACD group, according to RFC 6337 section 5.3 "the use of > sendonly/recvonly is not limited to hold". > > In the following discussion on this subject involving the authors of RFC > 3261 there is a clear indication that a RE-INVITE with-out an SDP should > not modify 'a=sendonly', unfortunately this isn't enough to support our > argument and our service providers protocol lead have determined that the > 3rd party is acting correctly and have asked for more evidence. > http://marc.info/?t=9873861431=1=2 > > We have also pointed out that RFC 3264 section 8 states that the offer MAY > be identical to the last SDP provided but are promptly r
Re: [Sip-implementors] The purpose of late offers
Alex, 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. Regards, _ Roman Shpount On Tue, Apr 23, 2019 at 5:13 PM Alex Balashov wrote: > 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 > ___ 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
ACK to 200 OK should be sent based on the route set, not VIA. Regards, _ Roman Shpount On Sun, Feb 10, 2019 at 7:48 PM 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Does UDP fragmentation of SIP packets violate RFC3261?
RFC 3261 does not prohibit receiving fragmented UDP packets. As far as I remember, handling fragmented UDP packets was a standard test during SIP interop. Sending fragmented UDP packets should be avoided since it negatively affects SIP protocol stability. P.S. For reliable SIP usage it is probably better to use SIPS or avoid firewalls. Firewall and router SIP handling is almost universally broken and should be turned of, if SIP usage is expected. _ Roman Shpount On Wed, Jan 2, 2019 at 6:32 PM Philipp Schöning wrote: > Sonicwall Firewalls are dropping fragmented SIP packets beginning with > SonicOS 5.8 by default. This is justified by the following sentence: > > > Fragmented UDP traffic, especially SIP traffic, is a clear violation of > > RFC protocol, which SonicOS Enhanced firmware 5.8 and above very strictly > > adhere to in these circumstances. RFC 3261 is the RFC standard for SIP > > traffic, and states the following: > > > > 18.1.1 Sending Requests The client side of the transport layer is > > responsible for sending the request and receiving responses. The user of > > the transport layer passes the client transport the request, an IP > address, > > port, transport, and possibly TTL for multicast destinations. *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.* > > > My question is now: Does this last sentence really mean, that UDP > fragmentation is violating RFC3261? > > There is also an additional statement on their page: > > > SonicOS enhanced firmware 5.6, which is no longer supported, was less RFC > > compliant on this, but 5.8 has enhanced security by becoming more strict. > > RFC 4693 goes into additional detail regarding security concerns of > > unnecessary packet fragmentation. > > Unfortunately RFC4693 covers a completely different topic. Is there any RFC > which covers the topic of security concerns when using packet > fragmentation? > > I only found this statement in an older posting: > > > SIP ALGs, STUN servers, etcetera, must allow UDP fragmentation unless > they > > are intentionally sacrificing interoperability for security reasons. > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-May/009187.html > > BR > Philipp > ___ > 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] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?
RFC 5057 is informational, not a standard. RFC 3261 specifies that dialog established using an INVITE transaction can only be terminated using a BYE message. Specifically in https://tools.ietf.org/html/rfc3261#section-12.2.1.2: If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) For INVITE initiated dialogs, terminating the dialog consists of sending a BYE. This does not specify what happens when re-INVITE gets a 404 response, since this is not something that should normally happen for the request with the dialog. Getting 404 to a re-INVITE means something went horribly wrong and terminating dialog by sending BYE is probably the right course of action. Regards, _ Roman Shpount On Fri, Dec 21, 2018 at 2:23 PM Moy Amiga wrote: > Thank you Roman. > > But about the RFC 5057, https://tools.ietf.org/html/rfc5057#section-5.1 > And I dont know if this RFC is for the NOTIFY only or also include a > INVITE message. > > > For the failure responses with code 400 and greater, there are three >common ways the failure can affect the transaction, usage, and dialog >state. > >Transaction Only The error affects only the transaction, not the > usage or dialog the transaction occurs in (beyond affecting the > local CSeq). Any other usage of the dialog is unaffected. The > error is a complaint about this transaction, not the usage or > dialog that the transaction occurs in. > >Destroys Usage The error destroys the usage, but not the dialog. > Any other usages sharing this dialog are not affected. > >Destroys Dialog The error destroys the dialog and all usages sharing > it. > >Table 1 and Table 2 display how the various codes affect transaction, >usage, or dialog state. Response code specific comments or >exceptions follow the table. > > +--++-+ > | Transaction Only | Destroys Usage | Destroys Dialog | > +--++-+ > | 400 (or unknown 4xx) |405, 480| 404, 410, 416 | > | 401, 402, 403, 406 |481, 489| 482, 483| > | 407, 408, 412-415 | 501 | 484, 485| > | 417, 420, 421, 422 || 502, 604| > | 423, 428, 429|| | > | 436-438, 486, 487 || | > | 488, 491, 493, 494 || | > | 500 (or unknown 5xx) || | > | 503, 504, 505|| | > | 513, 580 || | > | 600 (or unknown 6xx) || | > | 603, 606 || | > +--++-+ > > > > > > > -- > *Moisés Amiga* > > *Voice Operations* > > *Mex T.* + 52 (55) 5147 8040 ext 1367 > *Cel.* +521 55 2575 6848 > Llámame <http://callmenow.c3ntro.com/c3ntro1...@c3ntro.bicentel.net> > > Paseo de las Palmas 215-304 > Col. Lomas de Chapultepec, > México D.F. 11000 > > > > > > El vie., 21 de dic. de 2018 a la(s) 12:52, Roman Shpount ( > ro...@telurix.com) escribió: > >> Sorry, BYE message. I blame this on consistent fat-fingering. >> >> :) >> _ >> Roman Shpount >> >> >> On Fri, Dec 21, 2018 at 1:31 PM Alex Balashov >> wrote: >> >> > 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 >> >
Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?
Sorry, BYE message. I blame this on consistent fat-fingering. :) _ Roman Shpount On Fri, Dec 21, 2018 at 1:31 PM Alex Balashov wrote: > 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 > ___ 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?
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
Re: [Sip-implementors] Appropriate back-off response for overly frequent registrations
On Mon, Dec 17, 2018 at 9:29 AM Philipp Schöning wrote: > > > > > > If UDP is used for transport, empty UDP packets can be sent to keep the > >> NAT-binding alive. > >> > > > > Sending empty UDP is not standard complaint. Sending a STUN binding > > request, as described in > https://tools.ietf.org/html/rfc5626#section-3.5.2 > > is safer. > > > > This is not an option, if you are not using STUN. > There are lot of good reasons not to use STUN, e.g. because your IMS > provides sophisticated NAT traversal functionalities or your NAT type is > not compatible with STUN. > There are a lot of good reasons of not using STUN but there are no good reasons of not using STUN for UDP keep-alive. STUN keep-alive is extremely easy to implement. It is possible to verify packet validity and it can be used to detect local IP change. Regards, _ Roman Shpount ___ 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 5:36 PM Alex Balashov wrote: > On Thu, Nov 29, 2018 at 05:35:19PM -0500, Roman Shpount wrote: > Now that the philosophical question is out of the way, what's the right > SIP response? ;-) > > 480 (Temporarily Unavailable) with Retry-After header. You should also implement some sort of graceful service rejection logic which starts sending 480 if some pre-configured number of REGISTER requests were received from specific IP over pre-configured interval. Start dropping REGISTER messages if some pre-configured number of 480 requests were sent over the pre-configured interval. Regards, _____ Roman Shpount ___ 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 5:23 PM Alex Balashov wrote: > 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. > > Your best option is to figure out how to configure such devices so that they work properly. The next level you can achieve is to make sure devices that misbehave do not disrupt your service. Figuring out how to respond to devices that misbehave and still allow them to work properly is likely impossible (i.e. device will likely be flipping gateway status on/off, but you will need to verify this with each device individually). Regards, _____ Roman Shpount ___ 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 4:49 PM Philipp Schöning wrote: > There is no need to send REGISTER-Requests this often. > This will generate unnecessary load on the application level. > 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. If UDP is used for transport, empty UDP packets can be sent to keep the > NAT-binding alive. > Sending empty UDP is not standard complaint. Sending a STUN binding request, as described in https://tools.ietf.org/html/rfc5626#section-3.5.2 is safer. > When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to > keep the NAT-binding alive. > Agreed _____ Roman Shpount ___ 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 2:44 PM Alex Balashov wrote: > 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. > Windows 7 NAT (reusing ISP connection across multiple devices) has a 4 second timeout. This is why some devices has a very small keep alive interval. _ Roman Shpount ___ 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 2:33 PM Alex Balashov wrote: > 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. > 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). > 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. > 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. Regards, _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] REFER received before ACK, What should be done !!
Karthik, You desk phone seems to be broken. It should handle REFER or re-INVITE before ACK. There is no reason in any RFC why UA should generate an error message for the next INVITE or REFER request, if it is received before ACK from the previous transaction. The main purpose of ACK is to stop 200 OK re-transmission. It is very often re-ordered by the network or proxies with request that starts the next transaction. If you are going to generate error responses to re-INVITE received before ACK, you are going to have serious interop problems, since a lot of SIP service providers do exactly this (send a re-INVITE at the same time as ACK) when trying to limit call to a single codec. Also, you cannot rely on Retry-After header in error response, since it is not always supported. In a lot of cases Retry-After is ignored and call simply ends. Error response 491 is wrong here as well, since it is intended for two UA sending INVITE to each other at the same time, not same UA sending INVITE twice. It will still work for re-INVITE (not REFER) but it is not the intended usage. Regards, _ Roman Shpount ___ 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 6:13 AM, Olle E. Johansson <o...@edvina.net> wrote: > > >> > >> 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. > Ok, not seen that either. > > Skype For Business would be one example where SIPS client does not accept wildcard certificates. I definitely seen other clients that failed to validate wildcard certificates. Regards, _ Roman Shpount ___ 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
HI, My answers are inline: On Fri, Nov 17, 2017 at 3:21 PM, Alex Balashov <abalas...@evaristesys.com> wrote: > 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? > > 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? > This is true for at least some implementations. Your commonName must match the DNS name exactly. Keep in mind that if SRV records are used, commonName must match DNS name in the SRV record, not the host name in SIP URL. > 2. Is ';transport=tls' or ';transport=TLS' appropriate? I've seen both, > but which one is correct? > Neither. sips URL implies TLS transport. SIP can be used with transport=udp or transport=tcp, but not with transport=tls, which is not defined. There are multiple implementations that use sip URLs with transport=tls, but these are not standard. Also, transport URL parameter is not case sensitive, so ';transport=tls' and ';transport=TLS' should mean the same thing. > 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'? > See above. There is no 'transport=tls' defined. sips requires end-to-end use of TLS and does not allow any other transports. > 4. Is a 'sips:' URI scheme mandatory for secure transport? What are the > implications of a 'sip:' URI with ';transport=tls' affixed? > sips means end-to-end secure transport. It means that all Route URLs should be sips as well. Transport tls with sip URL is used to indicate that only specific hop is secure and other Route URLs can use other transports. This is how, for instance, OpenSIPS is using it. 5. Is it permitted for a proxy to bend a 'sips:' Request URI scheme to > 'sip:' when adapting TLS to an insecure transport? > No, according to the specifications, it is not allowed for the proxy to change sips to sip. There are numerous implementations which still do it. Regards, _ Roman Shpount ___ 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
Neel, There is no specification that branch parameter MUST be a RFC 4122 GUID. In fact, RFC 3261 branch parameters are never an RFC 4122 GUID since they starts with the magic cookie "z9hG4bK". All that it is required that branch parameter MUST be globally unique. Applications can generate branch parameter in any manner they choose as long as they can grantee uniqueness. Furthermore, applications can add any application specific information to the branch parameter for instance by base64 encoding with URL safe alphabet and adding it to the end of globally unique branch value. Since it is guaranteed that Via branch parameter will return to proxy which generated it without changes (otherwise proxy will discard the message), storing application specific data in branch parameter provides for a standard compliant, guaranteed to work mechanism for storing such data. On the other hand, using a custom Via parameter is not standard compliant and might cause issues with some of the implementations, similar to what Alex have experienced. Regards, _____ Roman Shpount On Thu, Oct 6, 2016 at 7:45 AM, Neelakantan, Neel <nneelakan...@sonusnet.com > wrote: > Hi, > > If branch parameter got introduced in 3261 and this MUST be GUID. > > From 3261: > >The branch parameter value MUST be unique across space and time for >all requests sent by the UA. The exceptions to this rule are CANCEL >and ACK for non-2xx responses. As discussed below, a CANCEL request >will have the same value of the branch parameter as the request it >cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx >response will also have the same branch ID as the INVITE whose >response it acknowledges. > > The uniqueness property of the branch ID parameter, to facilitate > its use as a transaction ID, was not part of RFC 2543. > > Thanks, > Neel. > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto: > sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roman Shpount > Sent: Friday, September 30, 2016 10:19 PM > To: Alex Balashov > Cc: Sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Arbitrary Via parameters > > On Fri, Sep 30, 2016 at 5:38 PM, Alex Balashov <abalas...@evaristesys.com> > wrote: > > > 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. > > > Via branch parameter is the transaction identifying parameter. Its format > and contents are implementation specific. There is no requirement for Via > branch (or SIP Call-ID for that matter) to be a GUID. All that is required > is that these parameters were unique. > > Regards, > _ > Roman Shpount > ___ > 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] Arbitrary Via parameters
On Fri, Sep 30, 2016 at 5:38 PM, Alex Balashov <abalas...@evaristesys.com> wrote: > 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. Via branch parameter is the transaction identifying parameter. Its format and contents are implementation specific. There is no requirement for Via branch (or SIP Call-ID for that matter) to be a GUID. All that is required is that these parameters were unique. Regards, _ Roman Shpount ___ 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
Well, I agree with you in theory, but this is one of those horses which has been out of the barn for a long time. No amount of standards clarifications will resolve this now due to how common it is to add customer parameters to SIP headers and how many of those parameters are now used in legacy applications. It might be a good idea to test and warn of such custom header use during SipIt events to avoid them in the future. 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. Regards, _ Roman Shpount On Fri, Sep 30, 2016 at 3:16 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > Roman, > > On 9/30/16 2:27 PM, Roman Shpount wrote: > >> On Fri, Sep 30, 2016 at 2:03 PM, Paul Kyzivat <pkyzi...@alum.mit.edu >> <mailto:pkyzi...@alum.mit.edu>> wrote: >> >> The inclusion of generic-param is a provision for future extensions >> with backward compatibility. It doesn't mean that anybody is >> *permitted* to add whatever they want. (It takes a published RFC to >> validly define a new header field parameter.) So if you *insert* >> values that haven't been properly defined and registered then you >> are violating the specs. >> >> >> This interpretation would break a lot of SIP implementations. The reason >> for this is that Via and Route generic parameters are used by stateless >> proxies to store application specific state. There is no other place to >> put it. Skype for business was one example. I can probably find another >> 10-15 examples similar to that from other products. >> > > Maybe it would. But I think it is more than simply *my* interpretation. > > RFC3427 says: > >Anyone who thinks that the existing SIP protocol is applicable to >their application, yet not sufficient for their task must write an >individual Internet-Draft explaining the problem they are trying to >solve, why SIP is the applicable protocol, and why the existing SIP >protocol will not work. > > And RFC3968 says: > >SIP header field parameters and parameter values MUST be documented >in an RFC in order to be registered by IANA. This documentation MUST >fully explain the syntax, intended usage, and semantics of the >parameter or parameter value. The intent of this requirement is to >assure interoperability between independent implementations, and to >prevent accidental namespace collisions between implementations of >dissimilar features. > > How can you read those to allow use of unregistered values? > > If there is need for this, then there ought to be a revision to carve out > a namespace for proprietary header field parameters, in general, or perhaps > only for Via. > > Thanks, > Paul > ___ 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 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 ___ 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 Fri, Sep 30, 2016 at 2:03 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > The inclusion of generic-param is a provision for future extensions with > backward compatibility. It doesn't mean that anybody is *permitted* to add > whatever they want. (It takes a published RFC to validly define a new > header field parameter.) So if you *insert* values that haven't been > properly defined and registered then you are violating the specs. This interpretation would break a lot of SIP implementations. The reason for this is that Via and Route generic parameters are used by stateless proxies to store application specific state. There is no other place to put it. Skype for business was one example. I can probably find another 10-15 examples similar to that from other products. Regards, _____ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] backoff algorithms to prevent registration storms?
When average processing time is below the normal processing time, then 200 OK response is sent to registration messages. Regards, _ Roman Shpount On Wed, Aug 10, 2016 at 4:22 PM, Michael <n...@spearheadcommunications.ca> wrote: > When the initial registration time is met, what code is send out from your > proxy server? > > Sent from my iPhone > > > On Aug 10, 2016, at 11:40 AM, Roman Shpount <ro...@telurix.com> wrote: > > > > Hi Paul, > > > > When dealing with a similar problem we have approached it on our edge > > proxies similar to traffic flow queuing disciplines (GRED to be precise). > > An edge proxy would measure average registration processing time for a > back > > end registration server. When average processing time exceeds the normal > > processing time limit (100 ms in our case), the edge proxy will start > > randomly refusing a gradually increasing percentage of the registration > > messages. When average processing time exceeds the overload processing > time > > limit (250 ms in our case), the edge proxy will refuse all registration > > messages. When registration messages were refused, proxy would send a 500 > > error response with Retry-After header set to a random value between 30 > and > > 60 s. > > > > Regards, > > _ > > Roman Shpount > > > > On Wed, Aug 10, 2016 at 11:00 AM, Paul Kyzivat <pkyzi...@alum.mit.edu> > > wrote: > > > >> I refreshed my memory on that draft. It proposes a new header field for > >> the registrar to tell the UA what to do after a failure. That may > indeed be > >> necessary for an ideal solution. > >> > >> Does anyone know of a documented approach using only *existing* sip > >> features? > >> > >>Thanks, > >>Paul > >> > >> > >>> On 8/10/16 10:45 AM, Paul Kyzivat wrote: > >>> > >>> Thanks to Volkan and Brett for this reference. I'll review it. > >>> > >>> Anybody else have something different? > >>> > >>>Thanks, > >>>Paul > >>> > >>>> On 8/10/16 10:35 AM, Brett Tate wrote: > >>>> > >>>> Hi Paul, > >>>> > >>>> The topic is discussed within draft-shen-soc-avalanche- > restart-overload; > >>>> however I don't recall why the draft didn't progress further within > >>>> soc or > >>>> dispatch. > >>>> > >>>> -Original Message- > >>>>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > >>>>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul > Kyzivat > >>>>> Sent: Wednesday, August 10, 2016 10:08 AM > >>>>> To: Sip-implementors@lists.cs.columbia.edu > >>>>> Subject: [Sip-implementors] backoff algorithms to prevent > registration > >>>>> storms? > >>>>> > >>>>> Strategies for preventing registration storms (e.g., after a major > power > >>>>> outage and recovery) have been discussed from time to time. > >>>>> > >>>>> Can anyone point me to specific documentation of such schemes? > Ideally a > >>>> spec > >>>> > >>>>> that can be referenced, but failing that I'll be happy with pointers > to > >>>>> thorough email discussions or non-standard implementations. > >>>>> > >>>>>Thanks, > >>>>>Paul > >>>>> ___ > >>>>> 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 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 mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] backoff algorithms to prevent registration storms?
Paul, I have mentioned this to your before, we also did registration message caching in our edge proxies to reduce the load on the back end registration servers. In our particular deployment, we did not show all the registrations for the AOR to the end point and we could cash the client credentials, which allowed for fairly efficient in-memory caching. Furthermore, in this deployment, edge proxies were responsible for inbound SIP message rate limiting (per IP and per /24 network), TLS to UDP proxy between the client and the back end, and overload protection which was based on the described algorithm. One thing to note was that a failure of the edge proxy often caused a load spike on other edge proxies due to clients detecting the TLS flow failure and re-registering, The overload protection algorithm was primarily in place to handle such load spikes gracefully. Regards, Regards, _ Roman Shpount On Wed, Aug 10, 2016 at 3:35 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > Roman, > > Interesting. That takes the load off the registrars, but the edge proxies > still must handle it. > > Thanks, > Paul > > On 8/10/16 1:40 PM, Roman Shpount wrote: > >> Hi Paul, >> >> When dealing with a similar problem we have approached it on our edge >> proxies similar to traffic flow queuing disciplines (GRED to be >> precise). An edge proxy would measure average registration processing >> time for a back end registration server. When average processing time >> exceeds the normal processing time limit (100 ms in our case), the edge >> proxy will start randomly refusing a gradually increasing percentage of >> the registration messages. When average processing time exceeds the >> overload processing time limit (250 ms in our case), the edge proxy will >> refuse all registration messages. When registration messages were >> refused, proxy would send a 500 error response with Retry-After header >> set to a random value between 30 and 60 s. >> >> Regards, >> _ >> Roman Shpount >> >> On Wed, Aug 10, 2016 at 11:00 AM, Paul Kyzivat <pkyzi...@alum.mit.edu >> <mailto:pkyzi...@alum.mit.edu>> wrote: >> >> I refreshed my memory on that draft. It proposes a new header field >> for the registrar to tell the UA what to do after a failure. That >> may indeed be necessary for an ideal solution. >> >> Does anyone know of a documented approach using only *existing* sip >> features? >> >> Thanks, >> Paul >> >> >> On 8/10/16 10:45 AM, Paul Kyzivat wrote: >> >> Thanks to Volkan and Brett for this reference. I'll review it. >> >> Anybody else have something different? >> >> Thanks, >> Paul >> >> On 8/10/16 10:35 AM, Brett Tate wrote: >> >> Hi Paul, >> >> The topic is discussed within >> draft-shen-soc-avalanche-restart-overload; >> however I don't recall why the draft didn't progress further >> within >> soc or >> dispatch. >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> <mailto:sip-implementors-boun...@lists.cs.columbia.edu> >> [mailto:sip- <mailto:sip-> >> implementors-boun...@lists.cs.columbia.edu >> <mailto:implementors-boun...@lists.cs.columbia.edu>] On >> Behalf Of Paul Kyzivat >> Sent: Wednesday, August 10, 2016 10:08 AM >> To: Sip-implementors@lists.cs.columbia.edu >> <mailto:Sip-implementors@lists.cs.columbia.edu> >> Subject: [Sip-implementors] backoff algorithms to >> prevent registration >> storms? >> >> Strategies for preventing registration storms (e.g., >> after a major power >> outage and recovery) have been discussed from time to >> time. >> >> Can anyone point me to specific documentation of such >> schemes? Ideally a >> >> spec >> >> that can be referenced, but failing that I'll be happy >> with pointers to >> thorough email discussions or non-standard >> implementations. >> >> Thanks, >> Paul >> ___
Re: [Sip-implementors] backoff algorithms to prevent registration storms?
Hi Paul, When dealing with a similar problem we have approached it on our edge proxies similar to traffic flow queuing disciplines (GRED to be precise). An edge proxy would measure average registration processing time for a back end registration server. When average processing time exceeds the normal processing time limit (100 ms in our case), the edge proxy will start randomly refusing a gradually increasing percentage of the registration messages. When average processing time exceeds the overload processing time limit (250 ms in our case), the edge proxy will refuse all registration messages. When registration messages were refused, proxy would send a 500 error response with Retry-After header set to a random value between 30 and 60 s. Regards, _ Roman Shpount On Wed, Aug 10, 2016 at 11:00 AM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > I refreshed my memory on that draft. It proposes a new header field for > the registrar to tell the UA what to do after a failure. That may indeed be > necessary for an ideal solution. > > Does anyone know of a documented approach using only *existing* sip > features? > > Thanks, > Paul > > > On 8/10/16 10:45 AM, Paul Kyzivat wrote: > >> Thanks to Volkan and Brett for this reference. I'll review it. >> >> Anybody else have something different? >> >> Thanks, >> Paul >> >> On 8/10/16 10:35 AM, Brett Tate wrote: >> >>> Hi Paul, >>> >>> The topic is discussed within draft-shen-soc-avalanche-restart-overload; >>> however I don't recall why the draft didn't progress further within >>> soc or >>> dispatch. >>> >>> -Original Message- >>>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >>>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat >>>> Sent: Wednesday, August 10, 2016 10:08 AM >>>> To: Sip-implementors@lists.cs.columbia.edu >>>> Subject: [Sip-implementors] backoff algorithms to prevent registration >>>> storms? >>>> >>>> Strategies for preventing registration storms (e.g., after a major power >>>> outage and recovery) have been discussed from time to time. >>>> >>>> Can anyone point me to specific documentation of such schemes? Ideally a >>>> >>> spec >>> >>>> that can be referenced, but failing that I'll be happy with pointers to >>>> thorough email discussions or non-standard implementations. >>>> >>>> Thanks, >>>> Paul >>>> ___ >>>> 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 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] SDP offer reject, fallback to previous state
Hi All: This is all based on https://tools.ietf.org/html/rfc3264#section-8 First it states: *We refer to the last SDP provided as the "previous SDP".* This clearly states last SDP sent , not the last SDP accepted. Then., later it states: *When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP.* So, based on this the version should be +1 of the version in the last sent SDP, i.e. 3. Regards, _____ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Handoff
On Tue, Jul 12, 2016 at 11:58 AM, Dale R. Worley <wor...@ariadne.com> wrote: > Paul Kyzivat <pkyzi...@alum.mit.edu> writes: > > ISTM that there is dubious likelihood of success of this is attempted > > after the previous connection has already failed. Make-before-break is > > safer if you can get some advanced warning. But make-before-break has > > its own implications on how you do this so that it doesn't become > > break-while-trying-to-make. > > At least in theory, you can make-after-break, since INVITE-Replaces can > snatch a call from an endpoint that is no longer reachable. (The remote > endpoint resends BYE many times, and then drops the dialog, but the > user interface is moved to the new dialog immediately.) > > As someone else noted, the important thing is to detect the break > quickly enough that the call can be reestablished before session timers > expire. > > You actually need to recover the connection before the transaction times out in order to make sure that SIP Session timer does not close the dialog. Session timer connectivity check and connection failure can occur at any time relative to each other. Because of this, connection can fail at the time of session timer connection check, no matter how often you check the connectivity. The only way to preserve the dialog is to reestablish the network connection while connectivity check is still running. This is, by the way, one more reason why we use UDP timers for TCP based messages -- it gives the client time to detect the connection failure and recover the connection. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Handoff
On Tue, Jul 12, 2016 at 11:48 AM, Dale R. Worley <wor...@ariadne.com> wrote: > Roman Shpount <ro...@telurix.com> writes: > > We actually always use UDP like re-transmits even when sending SIP > messages > > over TCP or TLS. There are enough implementations that connect TCP or TLS > > interface with UDP using a stateless proxy which make it necessary. > > Just last night, I found this requirement, which I had long forgotten: > > RFC 3261, section 16.1 > >Requests forwarded between different types of transports where the >proxy's TU must take an active role in ensuring reliable delivery on >one of the transports MUST be forwarded transaction statefully. > > That is, a stateless proxy is not allowed to send via UDP a request it > received via TCP. > I am actually well familiar with this requirement, but a lot of implementations do not follow this in practice. One of the reason are difficulties associated with fail-over of state-full transactions. Another issue you get when reusing long duration TCP connections is that end point can get a network error after SIP message is transmitted over TCP. At this point it is unclear if message was received by remote party or not. Re-transmitting the message on the timer can be the simplest solution since it also allows you to deal gracefully with short duration connectivity disruptions. Regards, _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Handoff
On Thu, Jul 7, 2016 at 2:28 PM, Volkan Hatem <vol...@hatem.net> wrote: > In fact, these were the cases where I doubted the reasoning behind "no > retransmission over TCP/TLS" for INVITE etc when you absolutely need it. > We actually always use UDP like re-transmits even when sending SIP messages over TCP or TLS. There are enough implementations that connect TCP or TLS interface with UDP using a stateless proxy which make it necessary. Also, in cases of IP connectivity disruption there is no way to find if the last message sent over TCP or TLS was actually delivered. Regards, _____ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Handoff
On Thu, Jul 7, 2016 at 11:49 AM, Dale R. Worley <wor...@ariadne.com> wrote: > My impression is that this problem is most commonly seen switching > between a mobile connection and a WiFi connection, but it can happen in > pure-SIP situations as well. > > So far, it seems that a UA could use INVITE-with-Replaces (sent from the > new interface to the other party) to transfer the dialog from its old > interface to its new interface. Has anyone implemented such a > technique? > We have implemented both INVITE-with-Replaces (when we controlled both the client and the B2BUA) and re-INVITE with a new Contact (when we controlled only the client). Both worked reasonably well. Since you need to detect the flow failure and place a new INVITE before session timer detects the call failure, some percentage of calls will always fail due to local transport failure. Either re-Invite with new Contact or INVITE-with-Replaces help to reduce the number of failed calls. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests
On Thu, May 21, 2015 at 10:23 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2015-05-20 23:13 GMT+02:00 Roman Shpount ro...@telurix.com: I think RFC 7118 example 8.2 is missing that language that WSS is used based on the local client policy. This would make the entire example correct and compliant with RFC 3621. From my point of view this is more of an editorial nit, then the actual specification issue, but this can be discussed in more details in sipcore. Let's clarify that in all the examples the client is connecting to an Outbound proxy, so it makes LOT of sense that it wants to keep and reuse the single connection it opened with the Outbound proxy for any future request (initial or in-dialog). That's seems implicit local policy IMHO, but yes, it should be specified somewhere. And IMHO the issue is in http://tools.ietf.org/html/rfc5630#section-3.1.3. Let continue with it: -- If one wants to use best-effort TLS for SIP, one just needs to use a SIP URI, and send the request over TLS. Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the header fields in a SIP message (From, To, Request-URI, Contact header field, Route, etc.). When TLS is used, the Via header field indicates TLS. --- There is the problem. Given that initial sip INVITE sent over TLS, how is supposed the proxy to indicate the client that it should send ACK and any in-dialog request over the same connection? There is no way for the proxy to indicate that, and there is the problem IMHO. I agree there is a real use case for the proxy to specify that it wants to use best effort TLS for one hop only. I doubt we will get it adopted though, since IETF now adapted a policy that everything must be secure, so they will not adopt partially secure solutions. In general, some sort of language that in practical deployments client would typically use a local policy to send all the SIP messages through a pre-configured WSS proxy would make a lot of sense. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests
On Thu, May 21, 2015 at 10:40 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2015-05-21 16:37 GMT+02:00 Roman Shpount ro...@telurix.com: In general, some sort of language that in practical deployments client would typically use a local policy to send all the SIP messages through a pre-configured WSS proxy would make a lot of sense. Yes, but how to make that compile with SIP routing rules? And why WSS? same applies to SIP over TLS. The local policy can (and often does) overwrite SIP routing rules. The main reason for this routing policy in WS SIP client is due to this client not being able to do proper DNS SRV record resolution, so SIP routing will need to be outsourced to a proxy with all SIP messages from the client to the proxy going over the existing WS (or more typically secure WSS) connection. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 5626 section 4.3: protocol to flow correlation
On Wed, May 20, 2015 at 10:39 AM, Brett Tate br...@broadsoft.com wrote: Concerning the following paragraph, what precisely does protocol mean within the protocol, IP address, and port snippet. For instance, are 1) TCP and TLS different protocols and 2) WS and WSS different protocols? I assume the protocol here means IP protocol value such as UDP or TCP. If TCP and TLS or WS and WSS end up pointing to the same IP address, protocol (both TCP) and port, then it would most likely represent a serious configuration issue, since there would be no easy way to correctly determine if TLS layer is used and what type of connection is being setup. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests
Brett, I think RFC 7118 example 8.2 is missing that language that WSS is used based on the local client policy. This would make the entire example correct and compliant with RFC 3621. From my point of view this is more of an editorial nit, then the actual specification issue, but this can be discussed in more details in sipcore. _ Roman Shpount On Mon, May 18, 2015 at 8:39 AM, Brett Tate br...@broadsoft.com wrote: In any case, there is no need for WSS URL transport parameter (as there was never a real need for tls URL transport parameter). Concerning tls, some apparently still find it useful since they continue to use it as mentioned within the following thread. http://www.ietf.org/mail-archive/web/sipcore/current/msg06531.html Is your intent to point the issue with the RFC example or to figure out the correct implementation strategy? I'm attempting to understand the various options for an edge proxy/B2BUA to request that the client continue to use the existing ws or wss transport (with/without use of RFC 5626). This led me to noticing RFC 7118 example 8.2 which appears to be incorrect or missing related normative text. Since I hadn't received a response on sip-implementors, I started a similar thread on sipcore last week. Since it sounds like errata potentially should be raised against RFC 7118, we should move this discussion to sipcore. http://www.ietf.org/mail-archive/web/sipcore/current/msg06605.html ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests
On Mon, May 18, 2015 at 6:12 AM, Brett Tate br...@broadsoft.com wrote: Thanks for the response. However, that snippet refers to proxy behavior instead of the client behavior. It looks RFC 5626 section 4.3 continues to have the client analyze Record-Route (or Contact) to determine the address, port, and transport. “The UAC performs normal DNS resolution on the next hop URI (as described in [RFC3263]) to find a protocol, IP address, and port. For protocols that don't use TLS, if the UAC has an existing flow to this IP address, and port with the correct protocol, then the UAC MUST use the existing connection. This is correct. In the RFC 7118 there should have been a SIPS URL in the record route. If it were a SIPS URL with transport WS, then the example would have been cleaner. In practice, though, all the WS SIP clients have a pre-configured WS SIP proxy and they send all the requests, including subsequent in dialog requests, through it. Since WebBrowser based clients can only do simple DNS resolution, they cannot do complete RFC3263 next hop resolution and they have to upload this to a proxy up stream. I think this was the intent of the provided example, but it was not clearly stated in the RFC. In any case, there is no need for WSS URL transport parameter (as there was never a real need for tls URL transport parameter). Is your intent to point the issue with the RFC example or to figure out the correct implementation strategy? _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests
On Sun, May 17, 2015 at 10:39 AM, Brett Tate br...@broadsoft.com wrote: Does this matter if SIP Outbound (RFC 5626) and GRUU (RFC 5627) are used? As far as I know, yes. Is there something within RFC 5626 which indicates that the client can disregard the Record-Route entry (such as address, port, and transport) added by the edge device? Yes, I think RFC 5626 describes something along this ( https://tools.ietf.org/html/rfc5626#section-3.2): When the proxy goes to forward a request to a given target, it looks and finds the flows over which it received the registration. The proxy then forwards the request over an existing flow, instead of resolving the Contact URIusing the procedures in [RFC3263 https://tools.ietf.org/html/rfc3263] and trying to form a new flow to that contact. So, essentially flow mechanism from RFC 5626 overwrites the actual address to which the SIP message is sent and the transport used. One other comment that I had was that sips URI with transport parameter set to ws should imply requests sent over secure web sockets. I do not think there is an explicit need for wss URI transport. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests
On Wed, May 6, 2015 at 11:01 AM, Brett Tate br...@broadsoft.com wrote: Concerning RFC 7118, wss was not defined as transport for SIP-URI. If dialog setup with transport=ws as a SIP-URI parameter within Contact or Record-Route entry when the connection is actually secured using wss (such as within RFC 7118 section 8.2 example), should wss continue to be used? Based upon RFC 7118 section 8.2 example (such as ACK sent over wss), I assume yes; however I didn't notice anything within RFC 7118 discussing the topic. Does this matter if SIP Outbound (RFC 5626) and GRUU (RFC 5627) are used? SIP over WebSockets is useless without SIP outbound or some other protocol that causes mid-dialog requests to flow over the existing connection established by the client. Regardless if connection is WS or WSS, the same connection will have to be used by the server, since it cannot establish a new connection to the client. In real implementations the value of the Contact is only used to populate the mid-dialog request URI or request URI for new calls directed to the client. It is not used to determine the message destination or the actual transport being used. I would also think that the Contact URL in that example should have been SIPS, not SIP if WSS was used. And that the subsequent forwarding should have been over TLS, not UDP. P.S. I think there is a great need of some sort of informational document that explains how SIP is supposed to work in NAT scenarios with connection oriented protocols, such as TCP. TLS. or WebSockets. It is a very confusing and typically mis-implemented scenario. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Do I need SDP in order to refresh an already established offer/answer session?
On Wed, Jan 7, 2015 at 6:14 PM, Manolis Katsidoniotis mano...@gmail.com wrote: I have an IMS scenario where offer/answer is complete, users are in talking state using one simple audio stream. (Much sooner than) half the session time, B side client is attempting to refresh the session using re-INVITE without SDP. A acknowledges the refresh with 200OK without SDP As far as I know this is not an error as session refresh does not require SDP,, however it is rejected by the servers with cause invalid offer/answer. Should I include the SDP nonetheless and keep the same session id version in the origin header? INVITE transaction without SDP in either INVITE or 200 OK is invalid. SDP should always be present in INVITE success response (either answer if SDP offer was sent in the INVITE or offer if no SDP was sent in the INVITE). One option is to send INVITE with the same SDP, which ideally should get you the same SDP in response, but you should be prepared for a different SDP as well. The better option is to do a session refresh using an UPDATE request without SDP. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] A Question about INVITE Server Transaction in RFC 6026
Caixia, I do not think specification missed anything. This is quite intentional. There is no limit of how long the caller can be dialing the number (as there is no limit on how long the caller can stay connected on a SIP call). If you need to put a limit on this duration, this will have to be application specific and does not need to be defined in the SIP spec. For instance you can define that dial timeout when placing the call is 1 minute and that will limit the duration of the proceeding state. Or you can set the dial timeout at 10 minutes. Or you can set this to be unlimited and let the caller hang up when they are done waiting for the call to connect. This is really up to you. The same way you can put maximum call duration at 24 hours and limit calls this way or you can let the caller hang up when they are done talking. _ Roman Shpount On Mon, Jun 23, 2014 at 5:45 AM, Caixia Liu caliu2...@gmail.com wrote: Hi Brett, Thanks a lot for your detailed analysis. Yes, the proceeding state is big issue to me. It seems spec missed this scenario, I have to retreat to an implementation specific behavior. Best Regards, Caixia ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive in-dialog requests after TCP disconnection
Inaki, You have misunderstood what I have said: The flow token is generated and added to the route header by the edge proxy. The flow token that edge proxy should put in the route header should be constructed in such a way that can be used to locate the registration from this particular user agent from this user. One way of doing this is to generate it in a manner similar to permanent or temporary GRUU. If flow token can be used to determine the registration it is referring to, for the subsequent requests you should be able to send it over any flow associated with this registration. Technically speaking, client is not forced in any way to be registered with anybody to use SIP outbound, or to use the flow associated with its registration to send its requests, so what I propose might not work in some cases. On the other hand, sip-outbound does not work for almost any common call scenario. The more I think about it, the more I am convinced that SIP Outbound should be rewritten. The way SIP Outbound should work is that every time a new flow is created from the client, a SIP registration should be send over this flow to associate it with an AOR. Response to this registration should include a flow token, that can be used by the edge proxy to reference data associated with the AOR and UID in the registration server. All subsequent requests sent by user agent over this flow should include an additional parameter in the VIA header that includes this flow token. It should be legal to send responses or new SIP messages to the user agent over any flow that is associated with the same AOR and UID. The continuation of this discussion should probably take in sipcore. _ Roman Shpount On Fri, Jul 27, 2012 at 7:34 AM, Iñaki Baz Castillo i...@aliax.net wrote: Hi Roman, sorry for the late response: 2012/6/18 Roman Shpount ro...@telurix.com: You can work around the issue you mention by putting the public GRUU in the route header instead of flow token. For all the subsequent requests proxy will look up if the flow exists for this GRUU and send the request over this flow. This is not safe. The outbound id token must be safely generated by the Outbound proxy (and not by the UA), in fact, the proxy should be able to check whether a outbound id token in a Route header has been created by the proxy itself. Overall I do agree with you that SIP Outbound is fairly raw, almost unimplementable spec which needs to be either updated or replaced (maybe with sip over websockets :). I have an idea in mind (which would be an extension to Outbound mechanism) so after a disconnection the UAC could re-register by asking the proxy to set the previous Outbound id token to the new connection (in this way incoming in-dialog requests would reach the UAC without the need of using GRUU). Regards. -- Iñaki Baz Castillo i...@aliax.net ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive in-dialog requests after TCP disconnection
Iñaki, You can work around the issue you mention by putting the public GRUU in the route header instead of flow token. For all the subsequent requests proxy will look up if the flow exists for this GRUU and send the request over this flow. Overall I do agree with you that SIP Outbound is fairly raw, almost unimplementable spec which needs to be either updated or replaced (maybe with sip over websockets :). _ Roman Shpount On Mon, Jun 18, 2012 at 4:26 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2012/6/15 Roman Shpount ro...@telurix.com: SIP Outbound is all about SIP clients operating from behind NAT, but it fails to address sending responses to SIP messages received over TCP. Hi Roman, as I told in my initial(s) mails in this thread, that's not the only problem. The worst problem, IMHO, is the fact that a single TCP disconnection using Outbound + Path + GRUU means that the SIP dialog gets useless (in at least one direction). -- Iñaki Baz Castillo i...@aliax.net ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive in-dialog requests after TCP disconnection
On Fri, Jun 15, 2012 at 4:50 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2012/6/15 Roman Shpount ro...@telurix.com: However I do a trick. If my proxy receives a request retransmission from a different IP:port, it updates its server transaction information so responses are now sent to the new IP:port of the UAC. So, if in the middle of a transaction the connection is broken and the UAC reconnects and re-send the request (retransmission) things would work with my approach. This trick relies on the client retransmitting request sent over the reliable transport. AFAIK most of the clients do not do that. Once request is sent over TCP, it is not going to be resent. Furthermore, even if the client is using something similar to UDP rules when retransmitting requests over TCP, it will not resend the INVITE after it receives 100 Trying. Because of this, if the client disconnects between getting 100 Trying and 200 OK for the INVITE (which is in my experience is the most common scenario affected by this issue, simply due to a much longer transaction duration), INVITE is never retransmitted and the client never gets the final response. From my point of view this is a serious issue and it requires some sort of specification to provide a solution for it. The way we are resolving this is by including GRUU in via parameters from our edge proxy. It works for us, since the same flow is never reused by several GRUUs and we can do GRUU by flow look-up. When edge proxy sends a response back and the original TCP connection is terminated, it detects if another connection was created for this GRUU, and sends the response via this connection. If no connection is present, we queue the response and send it over if client re-registers for this GRUU within certain time. __ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive in-dialog requests after TCP disconnection
On Fri, Jun 15, 2012 at 10:18 AM, Worley, Dale R (Dale) dwor...@avaya.comwrote: Strictly speaking, if the original connection is closed, RFC 3261 says that the response should be sent by resolving the host:port in the sent-by value using RFC 3263. This would be useful in high-availability situations (where a proxy might suddenly be fail, so we would want the host:port to be the SRV name of the proxy and its backup). But all phones that I've heard of will not resolve host names in the sent-by value. This is more or less what I've said. If a phone is behind a NAT, then there probably is no TCP sent-by value that would reach it. SIP Outbound is all about SIP clients operating from behind NAT, but it fails to address sending responses to SIP messages received over TCP. Typically, if you use ICE for NAT traversal of media, SIP message size forces you to send messages over TCP. Hence you end up with a NAT traversal solution which fails to function from behind NAT. From my experience with SIP outbound we see calls routinely failing because of this issue either during call setup or session refresh. Does anybody else think this requires either a new specification or a specification update? _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Outbound/GRUU/Path: NO way to receive in-dialog requests after TCP disconnection
On the related note, has anybody figured out how the response is supposed to be sent to a SIP message if the original TCP connection disconnects? Should we be putting some sort of flow tokens in the VIA header? The current specification says that response should be sent to the IP:port in the VIA header if original connection is closed, but this is almost universally useless for clients not located on a public IP. _ Roman Shpount From: I?aki Baz Castillo i...@aliax.net Subject: Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive in-dialog requests after TCP disconnection To: Olle E. Johansson o...@edvina.net Cc: sip-implementors@lists.cs.columbia.edu Message-ID: CALiegfnXJefZiHbp6J17ji_VT8A4JVpCgVRXOgsyd77hCzGE=a...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2012/6/14 Olle E. Johansson o...@edvina.net: I think this is mentioned: Section 5.3.2 ?Implementation note: Specific procedures at the edge proxy to ? ? ?ensure that mid-dialog requests are routed over an existing flow ? ? ?are not part of this specification. ?However, an approach such as ? ? ?having the edge proxy add a Record-Route header with a flow token ? ? ?is one way to ensure that mid-dialog requests are routed over the ? ? ?correct flow. Do we need a specification of this or is a solution just assumed? Hi Olle, the issue I talk about is not in the outbound proxy but in the registrar. For GRUU stuff to properly work, the registrar must be a proxy in the route set of the dialog and, when an in-dialog request has a GRUU URI in the RURI and arrives to the registrar, it must resolve the RURI and replace it with the corresponding binding in the location database, this is: - Alice sends an INVITE with her public GRUU as Contact URI. - Later Alice's registrar receives an in-dialog request from Bob, so the request has Alice's public GRUU as RURI. - The registrar MUST replace the RURI with the corresponding binding of Alice. This is: the request MUST arrive to Alice without her GRUU in the RURI. The issue I exposed in my mail occurs because the proxy/registrar in which I'm testing GRUU does not replace the RURI of the in-dialog request when it contains a GRUU, so it's a bug in the proxy/registrar (K.). Regards. -- I?aki Baz Castillo i...@aliax.net ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Sending TCP response with RFC 5626 after proxy restart
Well, I do not think you are correct. First of all, if UA receives a response over the second flow, it should process it properly based on the basic SIP specs. There is nothing in SIP specifications that implies that SIP transaction is associated with a particular TCP connection and should be terminated or retried if the connection is closed. It would normally time out but this is not something which is desired. RFC 5626 exists as a proposed solution for SIP connectivity for clients located behind NAT. It covers both server and client behavior, including request rerouting in case of flow failure. It does not cover the recovery mechanism for flow failure while sending a SIP response. The general SIP specification clearly does not work there since it directs to open a TCP connection to sent-by address and port from the VIA, which will fail in case of NAT. AFAIK there is nothing in any of the SIP standards that describes on how one should deals with this situation. I am bringing this to the mailing list to see if there any solutions that has been developed for this issue. The other, bigger question is, have anybody implemented a SIP client that reliably uses TCP/TLS from behind NAT? _ Roman Shpount On Fri, Jun 10, 2011 at 7:52 PM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/6/10 Roman Shpount ro...@telurix.com: 1. Client registers and creates two TCP flows to two different edge proxies 2. Client sends an INVITE message to edge proxy 1 which responds with 100 Trying and forwards it through the authoritative proxy to the final destination 3. Edge proxy 1 restarts and client flow to it is closed Hi Roman, I don't know very well RFC 5626, but I expect it does not cover the case you describe. In fact, your SIP UA does not need an extra specification for the case you describe: After point 3 above, your UAC should realize that the TCP connection has been closed so should terminate the transaction and, maybe, generate a new one. This is, AFAIK RFC 5626 exists for helping SIP TCP clients behind NAT rather than helping servers replying such clients after the TCP connection has been broken (since as you say, there is no real solution for that). -- Iñaki Baz Castillo i...@aliax.net ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Sending TCP response with RFC 5626 after proxy restart
I guess, my only issue with your argument is what is considered connection failure in TCP. I always assumed that this means not being able to establish a TCP connection. Connection closure after sending the request is not considered an error. TCP error while sending a request is not an error and typically requires another attempt to connect (otherwise connection reuse does not work). If connection closure is an error, then what is the point of 18.2.2: If that connection is no longer open, the server SHOULD open a connection to the IP address in the received parameter, if present, using the port in the sent-by value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. My solution was inserting a via parameter (I have reused the gr parameter in my case) which is set to private GRUU key for the GRUU associated with this connection. If the edge proxy no longer has the connection to the client, it checks the GRUU database if the valid flow exists, modifies the top via to match it and sends this request to another edge proxy. This is something that is not exactly standard but this seem to work and the only non-standard part is inside the proxy code I control. This helps to reduce number of call failures dues to proxy re-starts. The bigger question is, whether this warrant an RFC or if there is a better solution. _ Roman Shpount On Fri, Jun 10, 2011 at 8:23 PM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/6/11 Roman Shpount ro...@telurix.com: Well, I do not think you are correct. First of all, if UA receives a response over the second flow, it should process it properly based on the basic SIP specs. I never contradicted that. There is nothing in SIP specifications that implies that SIP transaction is associated with a particular TCP connection and should be terminated or retried if the connection is closed. It would normally time out but this is not something which is desired. I don't think so. RFC 3261 clearly says that if a TCP connection is closed while a client transaction was pending, the client transaction must generate a local 503 and pass it to the TU/core layer. The TU/core would then decide wheter to create a new transaction (i.e. based on DNS failover as RFC 3263 states). 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. The same for proxies: 16.9 Handling Transport Errors If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response. RFC 5626 exists as a proposed solution for SIP connectivity for clients located behind NAT. It covers both server and client behavior, including request rerouting in case of flow failure. It does not cover the recovery mechanism for flow failure while sending a SIP response. The general SIP specification clearly does not work there since it directs to open a TCP connection to sent-by address and port from the VIA, which will fail in case of NAT. AFAIK there is nothing in any of the SIP standards that describes on how one should deals with this situation. I fully agree. And honestly, I don't expect there is any solution for that. It doesn't matter whether the client had two connection (RFC 5626), as there is no way to server-1 to ask server-2 please, send you this response to the UAC as my connection with him has been terminated. The other, bigger question is, have anybody implemented a SIP client that reliably uses TCP/TLS from behind NAT? I've never seen yet a SIP client implementing RFC 5626. However, the best SIP TCP/TLS clients I've tested inmediately open a new TCP connection if the existing connection is terminated, and also register again using the new TCP connection. -- Iñaki Baz Castillo i...@aliax.net ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Sending TCP response with RFC 5626 after proxy restart
I am looking at implementation of RFC 5626 (SIP-OUTBOUND) and wanted to see what would be a proper scenario for sending responses for requests received over a flow which got disconnected before the response was sent. Imagine the following scenario: 1. Client registers and creates two TCP flows to two different edge proxies 2. Client sends an INVITE message to edge proxy 1 which responds with 100 Trying and forwards it through the authoritative proxy to the final destination 3. Edge proxy 1 restarts and client flow to it is closed 4. Authoritative proxy receives a response, and sends it edge proxy 1 based on flow 4. Edge proxy 1 receives the final response for the INVITE, but has no way to forward it to the client, and no way to signal the authoritative proxy that response needs to be re-routed through other proxy. So, the response fails even though client has a working flow through edge proxy 2 As far as I understand there is no way to recover from this situation or to deliver TCP response to a SIP client behind NAT, if the original request connection is closed. BTW, it looks like there is a recovery mechanism for sending requests to the client by addressing them to a GRUU URI and making the authoritative proxy re-route them over the alternative flow. I am looking for something similar for responses. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Encryption SDP attribute
No, I do mean encryption. The only place I found something describing it is here: http://msdn.microsoft.com/en-us/library/cc245997(v=prot.10).aspx http://msdn.microsoft.com/en-us/library/cc245997(v=prot.10).aspxI do see it in a few packet captures though and wanted to see where it came from. _ Roman Shpount On Tue, Jan 25, 2011 at 11:32 PM, Bob Beers bob.be...@gmail.com wrote: On Tue, Jan 25, 2011 at 12:26 PM, Roman Shpount ro...@telurix.com wrote: Does anybody know in which RFC a=encryption SDP attribute is defined? I see this attribute used in association with SRTP or RTP encryption, but I cannot find the standard or a draft that defined it. Do you mean a=crypto? RFC 4568? ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Encryption SDP attribute
Does anybody know in which RFC a=encryption SDP attribute is defined? I see this attribute used in association with SRTP or RTP encryption, but I cannot find the standard or a draft that defined it. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RFC 5626 TCP flow recovery during a dialog
Let me try to explain this better: 1. There is a sip-outbound enabled UA behind NAT. UA registers through an outbound enabled edge proxy with some registration server by sending REGISTER message over TCP. This creates a TCP flow between the proxy and the UA. 2. UA starts a call through the same edge proxy by sending an INVITE message over TCP over the same flow. Proxy inserts a record-route header where it stores the flow token and proxies the INVITE message to the call final destination. Other side responds, dialog is established and all the subsequent messages flow through this edge proxy over the same TCP connection. 3. Proxy server crashes and restarts. TCP connection to the UA is closed. UA detects that this flow failed, re-registers and creates a new flow though the same proxy. 4. A SIP messages for this dialog arrives to this edge proxy. New flow from UA is very likely to have different source IP and port (and even if ti does it should not be re-used since it can be a completely different client), so edge proxy will have no way of knowing that this connection should be used to communicate with this UA for the dialog. UA is behind NAT, so there is no way to open a TCP connection from the proxy to UA. My question is, is there any way to recover? Is there a way to fail-over to a different edge proxy? Or should we just accept that the call will fail in this case? P.S. Algorithm for generation flow tokens described in section 5.2 of RFC 5626 is dangerous, since it can result in SIP messages flowing to a different client if connection was closed and a different UA opened a connection using the same origination IP and port, which is common when multiple UA share the same NAT address. _ Roman Shpount - www.telurix.com On Tue, Aug 24, 2010 at 12:37 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 Roman Shpount [ro...@telurix.com] From what I understand, if TCP connection between the client and an edge proxy fails for any reason (proxy crash, for instance) and there is a dialog established which is using a flow to this proxy, this dialog will have to fail, since there is no way to route the dialog specific requests through any other flows. Is this correct, or am I missing something? _ RFC 5626 section 3.1 paragraph 2 makes it clear that any flow can be used to send a request to the UA. Similarly, RFC 3261 allows a request to be sent on a new TCP connection if the previous TCP connection has ended. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] RFC 5626 TCP flow recovery during a dialog
I was trying to figure out if RFC 5626 defines a recovery mechanism for TCP flow failure which occurs in the middle of an established dialog. From what I understand, if TCP connection between the client and an edge proxy fails for any reason (proxy crash, for instance) and there is a dialog established which is using a flow to this proxy, this dialog will have to fail, since there is no way to route the dialog specific requests through any other flows. Is this correct, or am I missing something? _ Roman Shpount - www.telurix.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Implementing RFC 5626 CRLF Keep Alive
Correction to my previous message: It is section 3.5.1 CRLF Keep-Alive Technique that I was referring to, not section 4.4.1. _ Roman Shpount - www.telurix.com On Thu, Jun 10, 2010 at 7:39 PM, Roman Shpount ro...@telurix.com wrote: Hi All, I am trying to implement CRLF Keep Alive mechanism from RFC 5626 and cannot decipher the meaning of the following phrase (from section 4.4.1) If a pong is not received within 10 seconds after sending a ping (or immediately after processing any incoming message being received when that 10 seconds expires), then the client MUST treat the flow as failed. What does immediately after processing any incoming message is supposed to mean? Does it mean that client should receive a a pong message after each incoming message? This makes no sense since getting a message on the flow already indicates that this connection is alive. Another question that I have is which side of the flow is suppose to generate the ping messages? The one that created a TCP connection? Both? Finally, do you know any SIP clients that implemented this RFC, which I can use for interop testing? Thank You, _ Roman Shpount - www.telurix.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
You are absolutely correct about RFC 3261. In regard of RFC 2543 the situation is a bit more tricky, since it never properly defines what matching To and From headers is supposed to mean. It does talk about saving complete To and From headers in the dialog state as local and remote addresses, and about matching those values against the To and From headers of the incoming requests. It would be safer to store complete headers in dialog state and reusing them in subsequent requests, unless the client specifically allows (and you have a compelling need) to change them. On the other hand, if client does not store and use header parameters in subsequent dialog requests, it should still be RFC 3261 compliant. This situation almost looks like RFC 3261 bug, since the intent of this specification is to be backward compatible with RFC 2543. Since header parameter are very rare, I don't think this affects a lot of implementation and probably because of of this are not properly covered in RFC 3261. Roman Shpount www.telurix.com Date: Fri, 19 Feb 2010 13:51:30 -0800 From: Anders Kristensen ankri...@cisco.com Subject: Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state? To: sip-implementors@lists.cs.columbia.edu Message-ID: 4b7f07e2.9010...@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Section 12.2.1.1 of 3261 talks about how the UAC constructs mid-dialog requests and it concerns itself with how From and To *URI* and tags are set. There's nothing in there suggesting that header parameters MUST or even SHOULD be retained. The part about 2543 compatibility also does not talk about header parameters. IMHO only the dialog state matters and that does not include the full From and To header fields. Thanks, Anders ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
From/To header should be preserved completely with all of its parameters to be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues Response says that The response MUST copy the To, From, Call-ID, CSeq and Via fields from the request. This implies that complete header, including all the header parameters are copied. The RFC 3261 should still match the request based on To and From tags. Older, RFC 2543 based user agents, will only match request to dialog if complete To and From headers are preserved. Roman Shpount www.telurix.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
The same section says that complete To and From fields including any tags are stored as remote and local address. Subsequent requests in dialog should set their To and From headers to remote and local addresses, which are complete To and From headers. This is done to be compatible with RFC 2543, where request would only match the dialog if complete To, From and Call-ID match. Roman Shpount www.telurix.com On Fri, Feb 19, 2010 at 3:22 PM, Paul Kyzivat pkyzi...@cisco.com wrote: Roman Shpount wrote: From/To header should be preserved completely with all of its parameters to be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues Response says that The response MUST copy the To, From, Call-ID, CSeq and Via fields from the request. This implies that complete header, including all the header parameters are copied. The RFC 3261 should still match the request based on To and From tags. Older, RFC 2543 based user agents, will only match request to dialog if complete To and From headers are preserved. That is pertinent to the *response* to the request. The question is about subsequent requests within the dialog. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other thantag) of From and To part of dialog state?
I think the key here that end point suppose to indicate that it supports changing To and From headers in the middle of the dialog. If such capability is not indicated, changing headers is not allowed. Roman Shpount www.telurix.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] draft-worley-service-example-02
Dale, How would you deal with re-Invite collisions between MOH server and the UA that you placed on hold? The normal re-Invite back-off will not work properly if it was your UA that established the call to the held UA (otherwise you can just use Retry-After header). You probably need a section or at least some discussion on what happens in that case. P.S. From my experience payload type restriction is really unnecessary and will just complicate compliant UA. _ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] few queries regarding SDP implementation formultiple bit rates for g.722 codec
G.722 codec is not defined for any other clock rates except 16KHz. This means that no matter what the SDP says, G.722 connection is used to pass 16KHz audio. On the other hand, there is a little complication caused by RFC 3551: RTP clock operates at 8Khz. This means timestamps should be incremented at the rate of 8000 units per second. In other words if you have 20 ms packets, the two consecutive packets will have their timestamps different by 160, not by 320 that would have been the case with 16KHz RTP clock. It looks like phone implementers get somewhat confused about this. Snom and Policom seem to get this right. CounterPath declares 8KHz timing in RTP but uses 16KHz RTP clock (10 ms packets with RTP timestamp incremented by 160). Grandstream declares RTP clock to be 16Khz and increments RTP timestamp accordingly. __ Roman Shpount On 8/8/07, Murat Artun [EMAIL PROTECTED] wrote: On 8/7/07, Roman Shpount [EMAIL PROTECTED] wrote: Hi All, m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/48000 a=rtpmap:9 G722/56000 a=rtpmap:9 G722/64000 This is definitely incorrect. The only clock rate supported by G.722 is 16KHz, which should be specified as 8KHz for compatibility reasons (see RFC 3551 4.5.2). This means the offer should be: m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/8000 So, should we interpret RFC 3551 section 4.5.2 that although RTP clock rate is announced to be 8000Hz in SDP, we should consider it to be 16KHz? Or what else, does G722 considered to be with clock rate 8000Hz in RTP although it is 16 KHz? Everything else is not standard and is not supported (except specifying the number of channels, such as a=rtpmap:9 G722/8000/1). Also, there is almost no reason to use any other G.722 bit rate except 64KB. All of those bit rates actually occupy 64KB of bandwidth. Lower bite rates simply leave space for a side channel inside the audio stream, which, IMHO, is not extremely useful in an IP environments. Furthermore, you can decode all of these bit rates as 64KB with minimal affect on the audio quality. ___ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- M u r at A r t u n, MSc. Design Engineer be conservative in what you do, be liberal in what you accept from others ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] few queries regarding SDP implementation formultiple bit rates for g.722 codec
Hi All, m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/48000 a=rtpmap:9 G722/56000 a=rtpmap:9 G722/64000 This is definitely incorrect. The only clock rate supported by G.722 is 16KHz, which should be specified as 8KHz for compatibility reasons (see RFC 3551 4.5.2). This means the offer should be: m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/8000 Everything else is not standard and is not supported (except specifying the number of channels, such as a=rtpmap:9 G722/8000/1). Also, there is almost no reason to use any other G.722 bit rate except 64KB. All of those bit rates actually occupy 64KB of bandwidth. Lower bite rates simply leave space for a side channel inside the audio stream, which, IMHO, is not extremely useful in an IP environments. Furthermore, you can decode all of these bit rates as 64KB with minimal affect on the audio quality. ___ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
