Re: [Sip-implementors] Sending deRegister request just after sending REGISTER request

> I haven't dug through the specifications. But if they have the > same Call-ID, then the CSeq tells the order the REGISTERs are > to have effect. If the network reorders them, the de-REGISTER > will prevail because it has a higher CSeq. My current understanding is that it depends upon implement

[Sip-implementors] indicating to send requests over TLS

Hi, What are the ways that a device determines to send mid-dialog requests using TLS over TCP? If I understand correctly, the following are some: 1 ) Although deprecated, sip-uri contains "transport=tls". 2) RFC 3263 NAPTR/SRV stuff. 3) RFC 5626 outbound stuff. 4) sips-uri is used with "trans

Re: [Sip-implementors] answer RTP/AVPF to offer RTP/AVP

Hi, Never mind. Since the RFC 5939 negotiation mechanism was being used within call flow associated with my question, it is valid from an offer/answer perspective. > -Original Message- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Thursday, May 25, 2017 12:56 PM &

[Sip-implementors] answer RTP/AVPF to offer RTP/AVP

Hi, Concerning the offer/answer model, is it valid to have answer SDP containing "m=" line with "RTP/AVPF" when the offer SDP "m=" line contained "RTP/AVP"? I didn't notice it being restricted by RFC 3264. RFC 4585 discusses offer/answer and mixed mode. However, I didn't notice the validity of

Re: [Sip-implementors] What is being rejected here?

> I've been scratching my head all day comparing branch branches, tags, and > call-ID's and I can't seem to pinpoint it. > > Does anyone have any suggestion what I (or SIPp) might be doing wrong? The request-uri within the ACK and BYE were not updated to reflect 2xx's Contact sip-uri. However, I'

Re: [Sip-implementors] race_condition

> Please help to understand situation described as " Race Condition" ! See RFC 5407. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

Hi, Sorry about the resend; however I wanted to mention that you also might want to look at RFC 5626 (and RFC 5627) since it updates RFC 3261. > -Original Message- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Friday, March 10, 2017 6:35 AM > To: 'Pu

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

> If a UA uses different dialog-ID (say new Call-ID & No To > header tag) for REGISTER refresh with same contact > address then it is allowed? Yes; however you should read RFC 3261 section 10. For instance, section 10.2.4 indicates "UA SHOULD use the same Call-ID for all registrations during a si

Re: [Sip-implementors] Query regarding

> I have a customer that has A PBX that sends a 200 OK with > a 200 OK with the PAI Header (with CRLF on two lines): > Is this type of header correct as per RFC ? Since your "instead of" example also appeared to have an extra CRLF (and was missing a quote), I couldn't determine from your exampl

Re: [Sip-implementors] Request for RFC section for UE behavior

Hi, Since I wasn't completely sure how you intended the RFC 3261 section 17.2.3 and 28.1 quotes to be applied to the question, be aware that just changing the Via branch (when resubmitting after 408) might cause 482 merged request as mentioned within RFC 3261 section 8.2.2.2. Thanks, Brett __

Re: [Sip-implementors] X-Forwarded-For for sip traffic

Hi, It sounds like you might want to look at RFC 7044 and RFC 7131 (and maybe historic RFC 5806); however I'm not familiar enough with the http's X-Forwarded-For to know for sure. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun

Re: [Sip-implementors] Request for RFC section for UE behavior

Hi, If INVITE sent again with the same Call-ID and From tag, the CSeq should at least be incremented and Via branch updated since it is a new transaction. RFC 3261 section 8.1.3.5 indicates that a retry may or may not be possible (the section does not specifically mention 408). However since 408

[Sip-implementors] RFC 7463: Contact within PUBLISH

Hi, The PUBLISH examples within RFC 7463 contain a Contact. Does anyone know if it has an intended meaning? RFC 3903 section 4 indicates that it has no meaning. It looks like RFC 7463 section 11.4 might be indicating that it has an intended meaning (although it might just be indirectly discussi

[Sip-implementors] RFC 7463: PUBLISH with To tag question

Hi, Some of the PUBLISH examples within RFC 7463 (sections 11.7, 11.9, 11.10, and 11.14) contain a To tag. Was that was intentional? RFC 3903 does allow PUBLISH to be sent within dialog. However, I'm not sure what within RFC 7463 is actually creating the dialog that is being shared unless maybe

Re: [Sip-implementors] SIP REGISTRTION INFO

> In our case the Call-ID: ee74e9624ebe1844 value us > differ from the previous one so the UAS should update > the binding and accept the REGISTER request instead > rejecting it with 401. 401 is associated with authentication. They have the right to generate 401 if they want. For instance, they

Re: [Sip-implementors] PRACK and Proxy Servers Compliant to RFC 2543

Hi, RFC 3261 and RFC 3262 attempted to be backward compatible with RFC 2543 devices. This includes ACK being the only request that does not generate responses and the potential for an intermediary to return 407 (or other responses) for an unknown request. There is an open issue about if "PRACK i

Re: [Sip-implementors] SIP Domain with single part

Hi, >From a SIP perspective, I'll assume that you are asking about hostname. See the ABNF within RFC 3261 section 25.1. It appears to allow a single part (i.e. toplabel). See Paul's response for more details. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [m

Re: [Sip-implementors] Semantics of parameters in URI username

iginal Message- > From: sa...@allegro-1.evaristesys.com [mailto:sasha@allegro- > 1.evaristesys.com] On Behalf Of Alex Balashov > Sent: Friday, November 04, 2016 9:57 AM > To: Brett Tate; sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Semantics of parameter

Re: [Sip-implementors] Semantics of parameters in URI username

> As far as I can tell from the RFC 3261 ABNF, it is > permitted to put SEMI and EQUAL in the username of > a URI, but it has no semantic validity. The user-parameter can help. However, be aware that some vendors add "user=phone" when user portion is absent or otherwise cannot be decoded as telep

Re: [Sip-implementors] Building route set from provisional responses

Hi, > Since these are B2BUAs, there are *three* different > early dialogs here: > - UAC:B2BUA1 > - B2BUA1:B2BUA2 > - B2BUA2:UAS > > All the rules regarding route sets, etc. apply > separately to each. I agree. However, I just wanted to mention that the 3gpp specs appear to be requiring B2BUA App

Re: [Sip-implementors] Building route set from provisional responses

> (1) Route set due to 180: , > (2) Route set due to 183: > > PRACK should be routed as per (2), which will > not be possible if route set (1) is used. > > Kindly guide where am I missing. The B2BUA needs to be smart enough to know to not relay the PRACK even though the Route might indicate to d

Re: [Sip-implementors] Building route set from provisional responses

> Suppose UAC receives multiple provisional responses > before confirmation of the dialog (2xx), and each > provisional response has a different set of Record-Route > headers. (Each provisional response is within the same > early dialog. i.e. same From-tag and To-tag.) > > In this scenario: > 1. S

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

> In the failed call I am being told by the provider > that their SBC sent a BYE because the 200OK for the > INVITE was received before it managed to send the > 200OK for the UPDATE, I have checked the RFCs and > can't find if the customer SBC is breaking any rules > by sending an 200OK for the INV

Re: [Sip-implementors] Wrong Server header value resulting no ACK

> So in a call from when UAS is sending response [1xx and 200OK] > with a Server header but with a faulty value in that header > as per ABNF. All other headers values are perfect in those > responses. Then UAC is not sending ACK and the call is not > getting established. > Is it an expected beha

Re: [Sip-implementors] New Invite with same call id received when Non-Invite server is in completed state

> There is a connected call with dialog id as (callid1, > from tag ftag1, to tag ttag1). When BYE is received at > UA1 it responds with 200 ok and starts running Timer J > timer(32 seconds). After 5 seconds a new INVITE is > received by UA1 having same callid as previous call(callid1) > and new fro

Re: [Sip-implementors] Branch Header in BYE

See RFC 3261 section 8.1.1.7. Your understanding is correct if the branch starts with the magic cookie (which is required by RFC 3261). > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of NK >

Re: [Sip-implementors] UAS behavior on receiving PRACK request after failed final response for INVITE

a 481 response." > -Original Message- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Friday, August 19, 2016 9:54 AM > To: 'Sourav Dhar Chaudhuri'; 'Sip-implementors' > Subject: RE: [Sip-implementors] UAS behavior on receiving PRACK request > after

Re: [Sip-implementors] UAS behavior on receiving PRACK request after failed final response for INVITE

> So what should be the expected behavior of UAS? As you noticed, RFC 3262 section 3 indicates "it MUST be prepared to process PRACK requests for those outstanding responses". With that said, vendors likely vary concerning how they handle the race condition. For instance, some might return 481;

Re: [Sip-implementors] backoff algorithms to prevent registration storms?

; 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

Re: [Sip-implementors] backoff algorithms to prevent registration storms?

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.c

Re: [Sip-implementors] SDP offer reject, fallback to previous state

> I've been unable to find an SDP version reference though... See RFC 4566 section 5.2 which indicates that the origin line is globally unique identifier. Because of this, it would be invalid to indicate version 2 again for the session if the SDP has changed. _

Re: [Sip-implementors] Order of parameters in FROM header

Hi, The ordering of SIP URI parameters is not significant. RFC 3261 section 20.20 (and indirectly section 20.39) mentions URI matching which is further discussed within section 19.1.4. RFC 3261 section 19.1.4: "The ordering of parameters and header fields is not significant in comparing SIP and

Re: [Sip-implementors] Maximum allowed length of branch parameter in Via

> Is there any normative reference in relation of maximum > allowed length of Via branch parameter. One of our vendors > is sending a very long branch parameter and resultantly > the SIP message is being rejected with a 400 response. We > need to support this behavior with any normative references.

Re: [Sip-implementors] Precondition negotiation in re-INVITE

7;t the call flow of concern. > Have only seen 200 OK response for a re-INVITE. Me too (except during testing). On Friday, 22 July 2016 9:57 PM, Brett Tate wrote: Preconditions within re-INVITE is discussed within RFC 3312, RFC 6141, and RFC 4032. RFC 3725 may also be of interest since yo

Re: [Sip-implementors] Maximum length allowed in SIP header TO, FROM, VIA

> Could you please provide us the boundary condition of > these SIP headers (TO, FROM, VIA). > Maximum length value allowed in these header. RFC 3261 does not impose a maximum size upon headers. However, section 18.1.1 does discuss the message size constraints associated with some transports. Ad

Re: [Sip-implementors] Precondition negotiation in re-INVITE

Preconditions within re-INVITE is discussed within RFC 3312, RFC 6141, and RFC 4032. RFC 3725 may also be of interest since your use case sounds like 3PCC. RFC 4032 section 4 discusses a 3PCC situation that you might hit. > -Original Message- > From: sip-implementors-boun...@lists.cs.co

Re: [Sip-implementors] Handoff

> 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? Yes; with B2BUA acting upon Replaces. If it matters, solutions using thi

Re: [Sip-implementors] ABNF Grammar Parsing issue for P-Served-User

> I also realised that errata was reported very recently > by you in March 2016. Yes; I was slow in opening errata after raising the issue in 2013 within the sipcore working group while we were working on the similar issue with RFC 3325. http://www.ietf.org/mail-archive/web/sipcore/current/msg057

Re: [Sip-implementors] ABNF Grammar Parsing issue for P-Served-User

> Unfortunately, I did not get your explanation clearly > > What is the errata? See the following link. https://www.rfc-editor.org/errata_search.php?rfc=5502 > What type of brackets need to be used for this case? RFC 5502 contains PServedUser-value = name-addr / addr-spec. See name-addr ABNF

Re: [Sip-implementors] ABNF Grammar Parsing issue for P-Served-User

> So my understanding from above grammar that the header value > [sip:+ACE34610520436;cic=+7...@tqf01.test.abc;sescase=term;regstate=unreg] > has not violated the ABNF.. Can you please confirm if my > understanding is correct ? Based upon what you supplied, you need to implement RFC 5502 errata 46

Re: [Sip-implementors] User Agent Info

> Is there any way to hide the User Agent header in SIP? > User-Agent: I'm not sure at what level you want to hide it. It is an optional header; thus you don't need to include it. Additionally see RFC 3261 section 20.41 concerning security exposure and making configurable. RFC 3323 section

Re: [Sip-implementors] Session Expire (BYE after 5 minutes of session expire)

Hi, If I understand your question, you are wondering why the BYE is sent so long after session expiration. If your interpretation of the call flow is correct, it sounds like the device didn't follow the RFC 4028 section 10 recommendation to send the BYE prior to expiration. You might want to ask

Re: [Sip-implementors] SDP boundary demarcation

> Can anyone point me the RFC which clearly states whether a new line is > mandatory/optional before/after every boundary line in SDP. I'm not positive what you mean by "every boundary line in SDP". The boundary lines are part of a multipart body; see RFC 2046. RFC 2046 section 5.1.1 and RFC 456

[Sip-implementors] RFC 5628: conversion of quoted SIP parameter values into xml

Hi, RFC 5628 section 7 example shows the instance value ("") within quotes. Should the quotes have been removed or kept? "" I'm asking since I've seen implementation example

Re: [Sip-implementors] Fwd: Regarding Allow header filed in INVITE message

> Can any one let me know what are the methods that > should be present in Allow header filed in INVITE > message from an UAC. See RFC 3261 section 13.2.1. You should include what you are capable of receiving within dialog. RFC 3261 section 13.2.2.1 also discusses potentially refining by the sta

Re: [Sip-implementors] Tel URI support in Contact Header

> Can TEL uri format be used/supported in SIP Contact Header? Yes. > What scenarios can we support TEL URI in contact Header Contact associated with dialog can only contain sip or sips (e.g. see RFC 3261 section 8.1.1.8, 12.1.1, and 12.1.2). I don't recall any other mandates that would prevent

Re: [Sip-implementors] UNKNOWN Transport type specified in VIA header

> If UAS receives a SIP message (over UDP/TCP in our > case) from peer and in this case there is only one > VIA header present and transport type of this VIA > header in UNKNOWN (Here, UNKNOWN transport type means > either we are not supporting this transport or the > transport specified in VIA hea

Re: [Sip-implementors] transport=udp|tcp|tls in contact header

> If SIP transport isn't UDP, transport=tcp or tls must be > presented in the contact header. Although, RFC 5630 says > transport = tls deprecated, many implantations still use it. A transport parameter is not required unless unable to determine it through other means such as the use of DNS NAPTR

Re: [Sip-implementors] [SIP-IMPLEMENTORS] Query related to Call Transfer

> I am reading the RFC5589 related to the Call Transfer. > In Examples it is mentioned as below > 6.1. Successful Transfer > Why in the CSeq Method value is REFER ? The RFC contains some errors. See errata 1892. https://www.rfc-editor.org/errata_search.php?rfc=5589 ___

Re: [Sip-implementors] Query in handling 180 response by proxy

Hi, The proxy would relay 18x responses from both locations. RFC 5359 section 2.9 shows a related example for Call Forwarding No Answer. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Ra

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

Hi, > > As far as I know, the main complaint is that it can > > temporarily prevent/delay honoring the DNS configured load > > balancing and priorities. > > So there is a consensus that transaction based DNS load > balancing is more preferable to the dialog based TCP > connection reuse? Meaning t

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

Hi, > Does this mean that there is even no recommendation to > reuse existing TCP connection for sending BYE request? For clarity, there are recommendations concerning the reuse of existing connections. For instance, see RFC 5626 section 4.3; similarly, RFC 5923 discusses the RFC 3261 persistent

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

Hi, > UAC (Caller) UAS(Callee) As an fyi, the UAC/UAS labels within the figure are not accurate since requests are sent is both directions. User Agent Client and User Agent Server are defined within RFC 3261 section 6. > 1. Can the refresher value be changed in the SE header > of the

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

> I think a UAS is forbidden to include a Session-Expires header field in > the > UPDATE request and a UAC should reject it. > In that case, the value of session refresher in 200 OK of INVITE MUST be > uac. I'm not sure why you think that it is forbidden. RFC 4024 table 1 shows that Session-Expir

Re: [Sip-implementors] : Query for refresher value in 200 OK of INVITE

> <---UPDATE > > (Session-Expires:3600;refresher=none) The header is malformed. The valid refresher values are indicated within RFC 4028 section 4. > [Query]: What should be the value of session refresher in 200 OK of INVITE? The refresher should be "u

Re: [Sip-implementors] non-invite request timer

> For non-invite transaction , example for message method > 200 ok response is receiving after 500ms. So client > starts to re-transmit the MESSAGE method before response > is reaching. Is it a valid behavior otherwise client has > to wait more than 500ms for receiving a response. Yes; it may take

Re: [Sip-implementors] UAS/Proxy behavior when the branch ID is same and the SIP method is different

> Can someone help me with any RFC reference on how a server or > a call statefull Proxy should handle a SIP BYE which is using > a wrong (duplicate) branch parameter ? RFC 3261 section 17.2.3 discusses the topic. The behavior depends upon magic cookie. If cookie, transaction matching uses Via b

Re: [Sip-implementors] authentication-info header

Hi, I agree with Paul that the header can be ignored; however the header is registered with IANA and is discussed within RFC 3261. It looks like the header is only defined for responses (although Table 2 may be incomplete). RFC 3261 may contain better quotes to ignore the header and continue pro

Re: [Sip-implementors] Default Value

> If P-Early Media Header is missing , what should be the > default value of the media stream to be taken? RFC 5009 section 8 indicates the following: "When receiving a message directed toward the UAC without the P- Early-Media header field and no previous early media authorization request has be

Re: [Sip-implementors] Codec negotiation when incoming re-INVITE has no SDP

Hi, Your conclusion appears to be a misinterpretation of SHOULD. I mention it because not following the SHOULD can have 3PCC related interoperability limitations. RFC 2119: "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances t

Re: [Sip-implementors] Codec negotiation when incoming re-INVITE has no SDP

Hi, The following are a few RFC snippets. As shown within RFC 3725 section 10.2, 3PCC is one of the users of re-INVITE without SDP. If a device does not support re-INVITE without SDP or doesn't offer all codecs that the UA is currently willing and able to use, it hinders interoperability during

Re: [Sip-implementors] Sip message method has a dialog or not

Hi, RFC 3428 section 3 indicates "MESSAGE requests do not establish dialogs." However, RFC 3428 does indicate the potential to send MESSAGE within an existing dialog. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs

Re: [Sip-implementors] sip version 3.C

> Sometimes people talk about SIP version 3, but that's a joke And a good excuse to quote draft-kaplan-sip-four-oh-00 which skipped version 3.0 when proposing version 4.0. :) "One may wonder why it isn't numbered SIP v3.0 - the answer lies in market research. After the equivalent of hundreds of

Re: [Sip-implementors] Accept Language Header syntax

> Is the following format of Accept-Language header allowed ? > > Accept-Language: en_US The ABNF doesn't allow it (underscore should be dash). RFC 3261 references RFC 2616; RFC 2616 section 3.10 discusses the language tags. Accept-Language = "Accept-Language" HCOLON [ lan

Re: [Sip-implementors] How is a VIA added as either a IPV4 address or IP6 Address by a Proxy/B2BUA

> If the B2BUA is supporting both IPV4 or IPV6 address, > which IP does the B2BUA place, its IPV4 or IPV6 address? It can populate whatever address it wants within the Via (although you might care more when populating Contact/Record-Route or Via's maddr). The Via's received parameter will be adde

Re: [Sip-implementors] Max length of To/ From headers

> Is their any specific length of To/ From header defined by the standard No. > In case no specific length is defined, is their any common-practice > for max length? RFC 3261 section 18.1.1 might provide you some guidance for message size minimums to support. The common practice is not cap the

Re: [Sip-implementors] Is it OK to put spaces b/w SIP and COLON in SIP URI

= "sip:" [ userinfo "@" ] hostport url-parameters [ headers ] > -Original Message- > From: Arun Arora [mailto:arun.arora@gmail.com] > Sent: Tuesday, November 10, 2015 6:14 AM > To: Brett Tate; sip-implementors@lists.cs.columbia.edu > Sub

Re: [Sip-implementors] Is it OK to put spaces b/w SIP and COLON in SIP URI

RFC 3261 does not allow it (RFC 2543 tended to be more vague concerning where whitespace was valid). If RFC 3261 intended to allow it, it would have used things like COLON instead of ":" within the ABNF. SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers

Re: [Sip-implementors] Need of From/To Tag in SIP Dialog

The Call-ID is obvious. The To tag helps handle forking situations. The From tag used to be optional during call setup. It became mandatory because a common issue was that devices and operators occasionally incorrectly classified re-INVITE as INVITE because the To tag was missing to help with th

Re: [Sip-implementors] Difference between a SIP 401 and SIP 407 Responses

> You are totally right, although I have a confusion here about > what proxy is challenging me with the 407 response code? An intermediary (proxy or B2BUA) is challenging the request. > I mean by the word proxy what does the server mean? RFC 3261 section 6 provides the definition of proxy. How

Re: [Sip-implementors] Ordering of Via field value parameters

I agree. My understanding is that the ordering of things within a header field value is only important if the ABNF and/or RFC explicitly indicate that they are. A similar question was asked within the following thread. https://lists.cs.columbia.edu/pipermail/sip-implementors/2015-August/03028 0.

Re: [Sip-implementors] In dialog UPDATE crossing reINVITE: allowed?

Hi, Please ask within a new email thread with correct title. When doing so, please indicate if you are more concerned from a client perspective or intermediary perspective? > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lis

Re: [Sip-implementors] 3pcc

11:20 AM *To:* Brett Tate; sip-implementors@lists.cs.columbia.edu *Subject:* Re: [Sip-implementors] 3pcc Thank you Brett, in the same example what should be the value of refer-to Header? should that be contact (or) From (or) Asserted identity On Tuesday, September 29, 2015 6:59 AM, Brett

Re: [Sip-implementors] 3pcc

> This discusses the R-URI, I was looking for the URI > in the replaces header. in the example in that. > Replaces: 425...@bobster.example.org;to-tag=7743;from-tag=6472 > > what is the guidance for "425...@bobster.example.org" > should this be the contact-header of the Dialog planning > to be repl

Re: [Sip-implementors] 3pcc

target.” *From:* K sipuser [mailto:subscriberaddr...@yahoo.com] *Sent:* Tuesday, September 29, 2015 8:53 AM *To:* Brett Tate; sip-implementors@lists.cs.columbia.edu *Subject:* Re: [Sip-implementors] 3pcc Thank you Brett. I was asking about the replaces-to header and the URI inside that. so

Re: [Sip-implementors] 3pcc

Hi, I'm not sure that I understand your question (although RFC 3891 section 4 likely answers your question). For instance, are you asking how to populate the REFER's Request-URI (if sent outside of dialog) or Refer-To (when using Replaces)? Either way, you'd likely want to use the Contact. You

Re: [Sip-implementors] In dialog UPDATE crossing reINVITE: allowed?

> Consider SIP-dialog between UA1 & UA2. > UA1 sends reINVITE to UA2, and immediately also an in-dialog > UPDATE (to send updated P-Asserted-Identity value). Sending a request such as UPDATE immediately after re-INVITE is valid. However as you observed if the requests are received out-of-order (be

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

> I agree with you but does not. > > Basically what they are saying is this: If SDP version number > is incremented then this counts as an update/new offer period. They can call it whatever they want. RFC 3261 says that the SDP must be ignored (i.e. it is not an updated answer or new offer). Ho

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

> The violation is: > > "When a reliable provisional response contains a session description, and > is > the first to do so, then that session description is the answer to the > offer > in the INVITE request. The answer cannot be updated, and a new offer > cannot > be sent in a subsequent reliabl

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

correctly, RFC 6337 might even recommend not including an SDP in that situation. > -Original Message- > From: Roger Wiklund [mailto:roger.wikl...@gmail.com] > Sent: Thursday, September 17, 2015 3:29 PM > To: Brett Tate > Cc: sip-implementors@lists.cs.columbia.edu > Subje

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

Hi, I assume that the INVITE contained an SDP and your example truly reflects a single dialog (i.e. 18x/2xx To tags are the same). According to RFC 3261 section 13.2.1, the SDP modification must be ignored. Thus it shouldn't cause the call to be released. With that said, some devices have confi

Re: [Sip-implementors] m lines after after SDP offer/answer exchange failure

Hi, RFC 6141 updates RFC 3261 and addresses some of the re-INVITE failure handling ambiguities. However, I'm not sure if it specifically addresses the topic. RFC 3261 section 14.1: "If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no

[Sip-implementors] RFC 7315: multiple P-Charging-Function-Addresses headers

Hi, RFC 7315 expanded the P-Charging-Function-Addresses ABNF to allow multiple comma separated fields. However, the following RFC 7315 section 4.5 snippet is similar to the RFC 3455 text. Section 4.5: "When present, only one instance of the header MUST be present in a particular request or respo

[Sip-implementors] RFC 3261: header field parameter ordering

Hi, RFC 3261 section 7.3.1 presents the following common header format. field-name: field-value *(;parameter-name=parameter-value) Does RFC 3261 or another RFC indicate if the order of the parameters defaults to being significant or insignificant? RFC 3261 section 19.1.4 indicates the parameter

Re: [Sip-implementors] Near end NAT traversal

You will likely be interested in RFC 5626 and RFC 3581. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Ananth Kollipara > Sent: Friday, August 28, 2015 7:10 AM > To: sip-implementors@lists.

Re: [Sip-implementors] R-URI on ACK

Hi, Another issue is that your Record-Route sip-uri used "lr=on" instead of "lr". RFC 3261 defines lr-param without a value. RFC 3261 section 16.12.1 has some loose routing and strict routing examples which may be of interest. > -Original Message- > From: sip-implementors-boun...@lists

Re: [Sip-implementors] Possible valid response code for PRACK?

> can any one help me to find in which real time scenario, > on behalf of PRACK, UAS generates 1XX, 3XX and 485 responses. Unfortunately, it depends upon who you ask. Some vendors interpret RFC 3262 as though PRACK is like any other request within dialog. Other vendors basically interpret it as

Re: [Sip-implementors] Message Body in BYE

> Question is "Is It OK/Valid to have a message body in BYE or not?" It is valid (although if received Accept header, you might want to check it before including the body). RFC 3261 table 2 shows Content-Type with a * for BYE. Additionally, 3GPP TS 24.647 mentions sending "application/vnd.etsi.a

Re: [Sip-implementors] SIP call forking and PRACK to 1XX responses

> So UAC should send the PRACK to each 183 received > (with new 'To Tag') from P2? >From an RFC perspective, the UAC must support INVITE forking interactions (i.e. potential for multiple early/confirmed dialogs). However as discussed within draft-jesske-dispatch-forking-answer-correlation-03, not

Re: [Sip-implementors] SIP call forking and PRACK to 1XX responses

> 1. In a ISUP to SIP interoperability scenario, does > SIP proxy need to PRACK all the 183 received since > the INVITE was forked by the next hope proxy P2? The PRACK is generated by the UAC. The proxy follows RFC 3262, RFC 3261, and RFC 6026 similar to other mid-dialog requests (such as BYE) an

Re: [Sip-implementors] Question about "order" parameter in NAPTR records

Hi, See RFC 2915 (or RFC 3403). Within your example, it looks like record 10 would be selected. "Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below

Re: [Sip-implementors] No Session Expire Header in 200 OK

Hi, Concerning the 408, I assume that a transaction stateful middle box generated it upon re-INVITE transaction timeout (or similar issue) hitting the "best response" behavior of RFC 3261 section 16.7. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:si

Re: [Sip-implementors] From Header value is getting changed from 100 trying to 200OK

Hi, > The URI is not used for matching in 3261. Concerning responses, neither is Call-ID, To, From, or number within CSeq. > So, in order to have better interoperability, you > should limit to matching the fields identified by 3261. In my opinion, the matching fields mentioned within RFC 3261

Re: [Sip-implementors] From Header value is getting changed from 100 trying to 200OK

Hi, The UAS is noncompliant to RFC 3261 (and RFC 4916). RFC 3261 section 8.2.6.2 requires that the response's To/From URI equal request's To/From URI. > So is UAC1 send ACK for this? Or UAC1 ignore > that 200OK due to the change in From header value? The UAC can basically act however it wants.

Re: [Sip-implementors] RFC 6665: Event header parameters

scope of "Event" header field parameters. In RFC 3265, the scope is ambiguous, which causes problems with the registry in RFC 3968. The new text ensures that "Event" header field parameters are unique across all event packages." > -----Original Message- > From: Br

[Sip-implementors] RFC 6665: Event header parameters

Hi, What does RFC 6665 section 5.4.2 mean concerning "MUST NOT be reused with any other event package". For instance, RFC 4235 registered call-id, to-tag, and from-tag; can those parameters be used by other event packages? Thanks, Brett - RFC 6665 section 5.4.2: "Any "Event" header field

Re: [Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

Hi, As you noticed (and indicated by the following snippet), the UAS did not send the 180 reliably. Thus the UAC should not have sent PRACK; UAS returning 481 is correct. RFC 3262 section 3: "The provisional response to be sent reliably is constructed by the UAS core according to the procedures

Re: [Sip-implementors] SDP attribute for hold and rersume

Hi, Based upon the shown message flow, the behavior appears to be incorrect. More specifically, it looks like UAC1 desired sendrecv within step 1. If UAC1 still prefers sendrecv, it should have offered sendrecv within step 5. The following are a few RFC snippets. RFC 3261 section 14.2: "A UAS

[Sip-implementors] RFC 5626 section 4.3: protocol to flow correlation

Hi, 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? "The UAC performs normal DNS resolution on the next hop URI (as described

Re: [Sip-implementors] RFC 7118: impacts of transport=ws on mid-dialog requests

> 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/sip

  1   2   3   4   5   6   7   8   9   >