Re: [Sip-implementors] Call hold with a=inactive

On 9/7/23 8:44 AM, Roman Shpount wrote: 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. +1 An offer should only be based on local preferences, because the other side can

Re: [Sip-implementors] How to differentiate Hold RTP and voice RTP

Arun, On 9/22/22 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? *Nothing* is certain here! The SSRC may be different, but not

Re: [Sip-implementors] Sip From header without user part

been sent as part of a test. If so the sender may intentionally be generating error cases to see if your implementation responds to them as it should. Thanks, Paul BR///Rakesh On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:

Re: [Sip-implementors] Sip From header without user part

On 8/4/22 8:11 AM, Rakesh wrote: Hi Team, I could see in a sip CANCEL message From Header as below From: "test" ;tag=3bbb9483d215d830c635372f8f181929 is this correct? Just looking at this, without regard for context, it is valid syntax. (The userinfo portion of the sip URI is optional.)

Re: [Sip-implementors] CSeq in subsequent Register messages

On 6/28/22 4:19 AM, Gilson Urbano Ferreira Dias wrote: Dale, The three pseudo-dialogs are for different AORs. It would be very helpful if you would post the full messages. Thanks, Paul Does this change anything in the analysis? Regards, Gilson Urbano

Re: [Sip-implementors] SIP REGISTER MESSAGE flow

Arun, Your query doesn't have enough context to understand the case. It does however appear to more likely to be something that should be answered by someone in the 3GPP IMS community. If you want an answer here please spell out your case in much more detail. Thanks, Paul

Re: [Sip-implementors] RFC 4028 UAS behavior requirement of Require header

Ranjit, BTW, did you notice that there is an erata applying to section 9 of RFC4028? If you didn't notice, it might be confusing you. On 5/28/21 5:59 PM, Paul Kyzivat wrote: On 5/28/21 4:40 PM, Ranjit Avasarala wrote: Hi Holi The RFC says UAS should add a Require: timer in response when

Re: [Sip-implementors] [sipcore] RFC 4028 UAS behavior requirement of Require header

On 5/28/21 4:40 PM, Ranjit Avasarala wrote: Hi Holi The RFC says UAS should add a Require: timer in response when UAC is the refresher to indicate to UAC that it is the refresher. But I think this is redundant as UAC anyway knows it is the refresher and does not need a reminder from UAS. The

Re: [Sip-implementors] 400 BadRequest

-- BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Paul Kyzivat Sent: den 23 februari 2021 17:41 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 400 BadRequest On 2/22/2

Re: [Sip-implementors] 400 BadRequest

On 2/22/21 9:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: Hi again ! Correction, there are of course not any "require: 100Rel" in INVITE, sorry I mixed things up ! BR/pj We have a vendor that is saying that they correctly answers initial INVITE with 400 BadRequest because the INVITE

Re: [Sip-implementors] reuse of payload type

phone-event/16000 a=ptime:20 a=maxptime:40 BR/pj -Original Message- From: Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> Sent: den 22 januari 2021 16:31 To: Sundbaum Per-Johan (Telenor Sverige AB) mailto:per-johan.sundb...@telenor.se>>; sip-impleme

Re: [Sip-implementors] reuse of payload type

On 1/22/21 7:55 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: [snip] As you can see the offer in initial INVITE have payload type 100: a=rtpmap:100 AMR/8000 The offer in 200OK also have payload-type 100, but now it is: a=rtpmap:100 telephone-event/8000 I believe that this is causing

Re: [Sip-implementors] Multiple Colon (:) as Header delimiter of name-value

ing to allow as much as possible. Thanks, Paul -Max On Fri., Aug. 14, 2020, 9:13 a.m. Paul Kyzivat, <mailto:pkyzi...@alum.mit.edu>> wrote: On 8/14/20 10:25 AM, Maxim Sobolev wrote: > Paul, there is no space between colon and the rest of the call-id in the

Re: [Sip-implementors] Multiple Colon (:) as Header delimiter of name-value

007.mcc748.3gppnetwork.org>... OK. If there is no space then I agree that the UAC is doing nothing wrong. Thanks, Paul -Max On Thu., Aug. 13, 2020, 8:15 a.m. Paul Kyzivat, <mailto:pkyzi...@alum.mit.edu>> wrote: Pravin, Gaurav, On 8/13/20 5:34 AM, Pravin Kumar wrote:

Re: [Sip-implementors] Multiple Colon (:) as Header delimiter of name-value

Pravin, Gaurav, On 8/13/20 5:34 AM, Pravin Kumar wrote: Hi Gaurav, You can refer to RFC3261 Call-ID ABNF syntax section: [RFC3261 - page 228] Call-ID = ( "Call-ID" / "i" ) HCOLON callid callid = word [ "@" word ] [RFC3261 - page221] word= 1*(alphanum / "-" / "." / "!"

Re: [Sip-implementors] SIP Session Refresh RFC 4028

On 8/6/20 8:39 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: Hi ! Details about refresher is missing in your description, but I believe that B2BUA should accept UAS(B) value ! I disagree with your conclusion. While there is no explicit information about the refresher, the commentary

Re: [Sip-implementors] Query on SIM swap

Since this discussion seems to be specific to 3gpp use of SIP I suggest you continue this discussion in some 3gpp-specific forum. On 5/11/20 7:50 PM, ankur bansal wrote: Hi Ranjit There is no clear specification saying UE should deregister when SIM is removed . But if refer multiple specs ,

Re: [Sip-implementors] Usage of "User-Agent" in SIP responses

On 4/28/20 1:08 PM, Maxim Sobolev wrote: Hi, I've noticed that in the last few years few implementations have gained popularity who use User-Agent in both requests and responses. Instead of User-Agent in requests and Server in responses which I always believed (perhaps incorrectly) to be the

Re: [Sip-implementors] Proxy handling of in dialogue request

Jason, On 3/20/20 1:22 PM, Alex Balashov wrote: The proxy will send the request onward to the next Route hop. If no further Route hops are available, it will consume the domain portion of the Request URI and send the request to that. For the complete story, *carefully* read section 16 of

Re: [Sip-implementors] requirement to play media stream while on hold?

On 2/19/20 10:01 PM, Dale R. Worley wrote: Paul Heitkemper writes: If you are placed on hold (a=sendonly), and the holder sends you a media stream, are you required to play it? I looked through RFC's 3261, 2327, and 3264, but I don't really see a requirement to actually play a media stream

Re: [Sip-implementors] SDP version

but I have also colleagues that are arguing that RFC 4028 is only valid for UA with support for timer. I think your view on the matter makes very good sense ! Thanks ! BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Pa

Re: [Sip-implementors] SDP version

Sorry, but I'm too lazy to compare those two messages byte by byte to see if they are identical other than the version number. I don't understand the point of your question. Are you looking for an excuse to increment the version number without checking if the SDP has changed? There is a

Re: [Sip-implementors] Query on SIP 488 response

On 12/15/19 12:31 AM, Ranjit Avasarala wrote: Hi I have a scenario where the terminating device responds with SIP 488 Not Acceptable here response. It is understood that the terminating device does not support any of the codecs that the incoming INVITE has. this issue occurred when a landline

Re: [Sip-implementors] Proposal for a mew SIP 4xx Error code

Ranjit, I see you cross posted this proposal to multiple lists. There is large overlap in readership of those lists, so this creates a mess. I'm going to reply here, because this is the best place for such a query. Please see inline below. On 10/29/19 12:05 AM, Ranjit Avasarala wrote:

Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

Ranjit, Based on the further detail you provide below I conclude that this is most likely a question about 3GPP IMS behavior and specifications. I suggest that you take this to a 3GPP forum. (I don't know what that would be. Hopefully one of the people here who are involved in 3GPP can make

Re: [Sip-implementors] session refresh

On 9/24/19 6:03 AM, Philipp Schöning wrote: This was most likely a typo, RFC 3264 describes SDP offer/answer model. Yes, it was a typo. Sorry. Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor Sverige AB) : Thank you, really helpful, but I need help on what I should

Re: [Sip-implementors] session refresh

On 9/23/19 5:00 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: Hi ! Can anybody help me find relevant RFC/other info on how UAS should handle re-INVITE that is intended as a session refresh and not for modifying the session ? A pure session refresh is something that can only be

Re: [Sip-implementors] Query regarding fallback to media after Fax

On 9/20/19 12:49 AM, Rohit Jain wrote: Hi All, I have a query that can a SIP device fallback from fax to audio again. Following is the scenario: User initiated a call with audio and call is connected. After this user sent a ReInvite with t38 fax and both offer answer are negotiated. Can a

Re: [Sip-implementors] renegotiate rtp <--> srtp in mid call

On 9/10/19 9:14 AM, J C Sunil Kumar Reddy wrote: Hi All, Can we renegotiate a rtp call to srtp and vice-versa in midcall? May be with re-INVITE or UPDATE message? Is it a valid scenario if srtp is not mandated? In my scenario, server and client both supports RTP and SRTP and initially call is

Re: [Sip-implementors] FROM-TAG(Local Tag) Need - Detailed Explained Req

Sridhar, Please do not try to learn SIP from RFC2543. RFC3261 replaced and obsoleted RFC2543 long ago. It is authoritative, but do please note that it has been extended and revised many times. (See the "Updated by" list at the top of https://tools.ietf.org/html/rfc3261.) If you are just

Re: [Sip-implementors] NOTIFY and Record-Route

d be used, and therefore it's incorrect that the re-SUBSCRIBE sends directly to the Contact address rather than using the Record-Routes in the NOTIFY. It's very helpful to have this knowledge as a reference! > > > On Thu, 25 Jul 2019 at 00:01, Paul Kyzivat <mailto:pkyzi...@alum.mit

Re: [Sip-implementors] NOTIFY and Record-Route

te used for *out of dialog* requests. If those requests establish a dialog then Record-Route is still used to establish the route set for subsequent in-dialog requests. Thanks, Paul On Tue, 23 Jul 2019 at 13:03, Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote: O

Re: [Sip-implementors] NOTIFY and Record-Route

le.com:5061>>;tag=155960081226925 Call-ID: 1552952...@xx.xx.xx.10 CSeq: 877 SUBSCRIBE Contact: Max-Forwards: 70 User-Agent: ewb2bua/15.4.3Alpha.2019053 Event: dialog Expires: 300 Content-Length: 0 On Tue, 23 Jul 2019 at 04:54, Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wro

Re: [Sip-implementors] NOTIFY and Record-Route

Inline On 7/21/19 6:42 PM, David Cunningham wrote: Hello, We have the following issue and are looking for some advice on the expected behaviour: 1. UAC sends SUBSCRIBE to UAS at x.x.x.x:5061, receives 200 OK in response. 2. UAS sends NOTIFY to UAC with Record-Route x.x.x.x:5061, Via

Re: [Sip-implementors] The purpose of late offers

to include in an initial offer. Thanks, Paul — 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

Re: [Sip-implementors] The purpose of late offers

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

Re: [Sip-implementors] Precondition is added into 200OK re-INVITE

as a result. Thanks, Paul Thanks, A.C Sent from my Samsung Galaxy smartphone. Original message From: Paul Kyzivat Date: 4/18/19 23:21 (GMT+07:00) To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Precondition is added into 200OK re

Re: [Sip-implementors] Precondition is added into 200OK re-INVITE

On 4/17/19 10:50 PM, Anh Cao wrote: Hi all, I meet a weird case with precondition but can not find any document talk about it: I make SIP call from my system to the fax machine. In the initial INVITE, my system includes precondition in Supported header and status in SDP. But fax machine does

Re: [Sip-implementors] XML Body in the 200 OK SIP Response of SIP MESSAGE

erwise it looks reasonable. Thanks, Paul Regards Abhishek On Sat, Apr 13, 2019 at 4:36 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote: On 4/13/19 4:43 PM, abhishek jain wrote: > Thanks Paul for your quick response on a Saturday. I really appreciate

Re: [Sip-implementors] XML Body in the 200 OK SIP Response of SIP MESSAGE

, Paul Regards Abhishek On Sat, Apr 13, 2019 at 3:08 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote: On 4/13/19 3:58 PM, abhishek jain wrote: >> >> Hi, >> Can a Sip Response (to a Non-Dialog creating SIP Request) contain a body ?

Re: [Sip-implementors] XML Body in the 200 OK SIP Response of SIP MESSAGE

On 4/13/19 3:58 PM, abhishek jain wrote: Hi, Can a Sip Response (to a Non-Dialog creating SIP Request) contain a body ? I would appreciate a quick response. Sometimes. The rules vary depending on the type of message. But not for MESSAGE. RFC3480 (section 7) says: A 2xx response to a

Re: [Sip-implementors] Cancelling an INVITE which did not got provisional response yet

On 3/13/19 5:45 PM, AXE MSC wrote: Hi, PCSCF has two realms. One is facing Core network and another is facing Access network. I have a scenario where PCSCF sends the INVITE to the handset facing Access realm. But no TCP ACK or SIP provisional response received from the handset. After 15 seconds

Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header

p. Thanks, Paul BR/// Rakesh Kumar Mohanty On Thu, Feb 7, 2019 at 11:07 PM Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote: Rakesh privately asked me why this doesn't conform to the ABNF of a sip message. I'm replying to the list f

Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header

Rakesh privately asked me why this doesn't conform to the ABNF of a sip message. I'm replying to the list for the benefit of others. Here is some of the relevant ABNF: SIP-message= Request / Response Request= Request-Line *( message-header )

Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header

Rakesh, I still don't understand your question. What you show below appears to be garbage that happens to include a few fragments that resemble sip URIs. Did you receive this on a port where you expect to receive sip messages? If so, this clearly doesn't conform to the ABNF syntax of a sip

Re: [Sip-implementors] Reflection of non-registered SDP attributes

On 1/30/19 10:23 PM, Dale R. Worley wrote: It's a fascinating problem. In a way, inserting a unregistered attribute is forbidden, but any recipient is forbidden from objecting to it. OTOH, if the attribute is unregistered, you can't really say that the endpoint using it in its answer is

Re: [Sip-implementors] Reflection of non-registered SDP attributes

On 1/29/19 11:29 AM, Alex Balashov wrote: Hello, On Tue, Jan 29, 2019 at 11:21:01AM -0500, Paul Kyzivat wrote: 5.13 says: "Attributes MUST be registered with IANA", so why do you say this isn't illegal? Upon reflection, you are certainly correct. I suppose the notion of lega

Re: [Sip-implementors] Reflection of non-registered SDP attributes

On 1/29/19 10:21 AM, Alex Balashov wrote: Hi, I am using a media relay which implements some internal loop detection by adding a non-IANA-registered SDP attribute to any offer or answer that passes through it: a=CustomAttribute:GUID From what I understood from RFC 4566 § 5.13, this isn't

Re: [Sip-implementors] Dynamic payload number during renegotiation. RFC 3264

Oleksandr, On 1/17/19 3:47 AM, Oleksandr Fadieiev wrote: Hello dear team. Could you please help determine if RFC 3264 violated in the following scenario? Unfortunately, I wasn’t able to find appropriate email thread to answer my question. And I'm sorry for lengthy explanation. Scenario. 1)

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

On 12/21/18 2:34 PM, Roman Shpount wrote: 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

Re: [Sip-implementors] Question on Offer/Answer Model with SIP

type has been used earlier in the call for an rtp session then it can't be used for a *different* codec or codec configuration later in the session. Thanks, Paul Regards, Amarnath On Wed, Dec 19, 2018 at 10:19 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>&

Re: [Sip-implementors] Question on Offer/Answer Model with SIP

Amarnath, Take a look at RFC6337 for an in-depth treatment of offer/answer issues and best practices. More below, consistent with what is in that rfc. On 12/19/18 12:28 AM, Amarnath Kanchivanam wrote: Hi, I have below call flow and would like to know the correct behavior. UAC

Re: [Sip-implementors] Query about Content-Type when Content-Length = 0

On 12/7/18 5:12 AM, Hamza Mohamed Salman wrote: Dear, Good Day. The trace result shows that The 480 arrives to the node, and it is rejected (dropped) because there is a fault in the message. The following is seen in the communication buffer of the TEST SYSTEM trace we receive yesterday.

Re: [Sip-implementors] RTP with wrong payload

a=cpar:a=T38FaxMaxDatagram:1472 a=cpar:a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv BR/pj -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat Sent: den 15 november 2018 17:37 To: sip

Re: [Sip-implementors] RTP with wrong payload

On 11/15/18 1:21 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: I should have given more details, in the example I gave there was actual a couple of G.722 packets that was marked with payload type G.722 received in a session where G.711A(PCMA/8000) was established as the agreed codec, the

Re: [Sip-implementors] t.38 port equal 0 in SDP

On 9/15/18 5:32 AM, Qter wrote: Dear Experts, I see that one device is sending re-INVITE message with such SDP parameters: v=0 o=- 1092631119 2 IN IP4 10.10.10.100 s=- c=IN IP4 10.10.10.100 t=0 0 m=image 0 udptl t38 m=audio 29044 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - The

Re: [Sip-implementors] REFER received before ACK, What to do!!

On 9/6/18 1:05 AM, karthik sasupalli wrote: Hi All, I have a scenario, where the REFER to an INVITE is received before the ACK. There is a Desk Phone and a Call server. The call is initiated by the Call server. Desk Phone <-- INVITE <-- Call Server Desk Phone --> 180 Ringing --> Call Server

Re: [Sip-implementors] MSRP SEND's CPIM From header - display name in URI

On 9/4/18 1:56 PM, Nancy Greene wrote: This question came up when we started to look at display name in a CPIM From header of an MSRP SEND (RFC4975): If you put quotes around a display name (called Formal-name in RFC3862), then you do NOT put a space after the end quote and the "<" of the

Re: [Sip-implementors] 401 Unauthorized with Require Header?

On 8/16/18 1:21 AM, Sreekanth wrote: On Thu, 16 Aug 2018 at 08:31, Dale R. Worley wrote: Sreekanth writes: I am going through the SIP RFC (3261) and couldn't find anything specified regarding the 401 Unauthorized challenge response from the UAS side during a registration. I wanted to

Re: [Sip-implementors] Offer/answer model in early media with forking

On 7/16/18 1:17 PM, Alex Balashov wrote: Hi, I have a scenario where a call is forked through a proxy to an early media announcement server and then subsequently to a SIP provider for actual termination. Due to the way the RTP relay works on the server side, this results in two different SDP

Re: [Sip-implementors] RFC 6337, Section 5.3. Hold and Resume of Media

Parveen, On 7/10/18 4:24 AM, Parveen Aggarwal wrote: Hi Experts, I have below scenario 1. A Calls B with "sendrecv" 2. B holds call with "sendonly" 3. A holds call with "inactive"-- both A and B media direction is " *inactive" *now Now, If B receives re-invite without SDP what should be

Re: [Sip-implementors] SIP 422 and RFC 4028

on whether they are compliant as UAs, not as proxies. Thanks, Paul On July 3, 2018 10:20:41 AM EDT, Paul Kyzivat wrote: On 7/3/18 3:53 AM, Alex Balashov wrote: No, it's not illegal to retry a call to the same gateway (in case of 6xx response). Nor is it illegal to reject

Re: [Sip-implementors] SIP 422 and RFC 4028

On 7/3/18 6:15 AM, Aman wrote: I find out an interesting conversation exactly about my scenario, when RFC 4028 was a draft and was in discussion mode, https://www.ietf.org/mail-archive/web/sip/current/msg00743.html Call flow: UAC - P-A - P-B -- UAS 1. UAC sends a simple INVITE w/o

Re: [Sip-implementors] SIP 422 and RFC 4028

On 7/3/18 3:53 AM, Alex Balashov wrote: No, it's not illegal to retry a call to the same gateway (in case of 6xx response). Nor is it illegal to reject it. :-) My experience in an applied sense with SSTs (SIP Session Timers) is that they are poorly supported, seemingly due to all the

Re: [Sip-implementors] Media Port change during Hold/resume

On 6/8/18 11:29 AM, Parveen Aggarwal wrote: Dear Experts, I am facing one scenario: 1. Make video call: Audio and video port non-zero 2. downgrade video call: audio port non-zero and video port 0 3. Network hold the call: audio:sendonly , video port 0 4. network sending re-invite without SDP,

Re: [Sip-implementors] Call failure after ReInvite

they can. But the state of the session is undefined in that case. Thanks, Paul Best Regards, Abhishek Phadke On 23-May-2018, at 22:38, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: Abhishek, On 5/23/18 7:15 AM, Abhishek wrote: Hello, SS7 Switch —> Gateway Switch —> S

Re: [Sip-implementors] Call failure after ReInvite

Abhishek, On 5/23/18 7:15 AM, Abhishek wrote: Hello, SS7 Switch —> Gateway Switch —> SIP SBC Call flow is as mentioned. SIP call gets established between Gateway Switch node and SIP SBC node. Gateway Switch node initiates Re Invite without SDP. SIP SBC node responds with 200 OK along

Re: [Sip-implementors] To tag in 407 challenges

requires that the tag be present. It would make no sense to try to change that at this late time. So the UAS should simply do as it is required to do - generate a tag and put it in the response. Thanks, Paul On March 25, 2018 6:27:03 PM EDT, Paul Kyzivat <pkyzi...@alum.mit.

Re: [Sip-implementors] To tag in 407 challenges

On 3/25/18 5:26 PM, Alex Balashov wrote: Hi, Are 407 challenges meant to have a To tag? If so, I can't find the rationale in 3261. Any pointers would be appreciated. (working from memory) An argument against to-tag in 407 would presumably apply equally to any 3xx, 4xx, 5xx, or 6xx. One

Re: [Sip-implementors] Codec Negotiation issue

On 2/22/18 3:34 AM, Rakesh wrote: Hi Expert, I have a scenario here can anyone help me to undrstand is the behaviour is correct on both cases? FIRST CASE: • User A calls User B • Negoziation for EVS codec • User A put in hold User B • REINVITE from User A, contains sendonly, with only EVS

Re: [Sip-implementors] 200 OK Retransmission

On 1/3/18 7:54 PM, onewhoknows wrote: Hello, I have an issue with some older releases of Asterisk talking to an Avaya PBX. I think there's a network issue somewhere, but in the meantime, I'd like to know which side is handling the following transaction correctly: Asterisk > Avaya Invite > <

Re: [Sip-implementors] Different TO Tag in SIP Bye as compare to SIP 200 OK

On 11/29/17 9:50 PM, NK wrote: Dear All, I have the problem where the customer is sending the BYE after 200 OK, but my switch refused to identify the dialog and sent the SIP 481, and I feel this is because of different TO tag. SIP 200 OK in the correspondence of initial Invite. *Switch to

Re: [Sip-implementors] Changing in "o=" field

On 11/20/17 5:27 AM, wisniawy wrote: Hello My Application Server sends a re-INVITE to the called party pointing in the SDP a Media Server instead of calling party IP address (included in original INVITE). INVITE: o=BroadWorks 204147 1 IN IP4 10.8.91.9 re-INVITE: o=BroadWorks 204150 1

Re: [Sip-implementors] Reinvite/ACK race

On 10/31/17 8:44 AM, Liviu Chircu wrote: Hi Alex, IMO, building logic into the proxy which encourages/mends the proper sequencing of UDP messages does nothing more than to hide the underlying problem, i.e. "UDP does not guarantee message sequencing in the first place" *. There is also a

Re: [Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying

(disclaimer: while I know quite a bit about SIP I know nothing about these CNAM query mechanisms. AFAIK none of these mechanisms are covered by IETF standards.) On 10/30/17 1:25 AM, Alex Balashov wrote: Hello, I apologise for cross-posting this from VoiceOps, and concede that it is an

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

e? Br, Ivo On Tue, Oct 10, 2017 at 8:37 PM, Paul Kyzivat <pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>> wrote: On 10/10/17 12:33 PM, Ivo Vastert wrote: Hi, I have a question regarding possible codec re-negotiation in a Referred-by s

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

On 10/10/17 12:33 PM, Ivo Vastert wrote: Hi, I have a question regarding possible codec re-negotiation in a Referred-by scenario. We have the following situation: A UA which has 2 legs open to a SBC / B2BUA. 1 Leg is on G729 and 1 Leg on G722. The UA is sending a Referred by towards the SBC

Re: [Sip-implementors] Network Initiated De-registration

On 10/6/17 10:29 PM, Dale R. Worley wrote: Paul Kyzivat <pkyzi...@alum.mit.edu> writes: On 10/6/17 1:04 PM, Abhishek Jain wrote: 1. Under what senarios or conditions, Network would initiate deregistration to a UE ? The only reason that is covered by ietf sip standards is expi

Re: [Sip-implementors] B2BUA behavior in correlation of Pre-Conditions & Multiple Early Dialogs

On 10/6/17 2:42 PM, VARUN BHATIA wrote: Hello, As a B2BUA what is the expectation when it is sitting behind a forking proxy (IMS Application Server) and it is sending back multiple early dialogs back. 1. It should ideally send it back transparently to ingress i.e. creating multiple early

Re: [Sip-implementors] Network Initiated De-registration

On 10/6/17 1:04 PM, Abhishek Jain wrote: Hi, 1. Under what senarios or conditions, Network would initiate deregistration to a UE ? The only reason that is covered by ietf sip standards is expiration of the registration without renewal. Other reasons would be based on policy. For instance,

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

On 10/4/17 4:20 PM, Andrew Pogrebennyk wrote: Hi, I understand that there is no normative document for a B2BUA but in general as common sense dictates should the B2BUAs that generate multiple outgoing requests on their UAC side for a single incoming request due to parallel forking create unique

Re: [Sip-implementors] 183 session

On 9/19/17 11:28 AM, Verma, Salil (Nokia - IN/Noida) wrote: Hi , Please help me to understand the difference between 183 with SDP and without SDP. A 183 without SDP has no role in the offer/answer process. It mostly just says "I'm working on your call." In the absence of the 100rel option

Re: [Sip-implementors] SBC sending 403 Forbidden when UE includes Anonymous in From header's user part

On 9/19/17 6:39 AM, Abinash Sarangi wrote: Hi Experts, We are facing an issue wherein INVITE sent by UE is being rejected by SBC with 403 Forbidden This is a *policy* issue rather than a *protocol* issue. The response indicates that the callee (or the SBC acting on behalf of the callee) has

Re: [Sip-implementors] Offerless Re-INVITE

Rakesh, See comments below. On 9/7/17 11:43 AM, Rakesh wrote: *Hi ,* *Can any one tell me what will be the codec can be sent on 200OK in below ?* *Is this the one that support by UE or the Supported codec by Proxy ?* *UA Proxy *>>*

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

now enough about its behavior to work around its brokenness, but then you're inventing some other protocol for a specific deployment and the specs can't help you. RjS On 8/1/17 11:03 AM, Paul Kyzivat wrote: On 7/31/17 11:49 PM, Prakash K wrote: Hi Paul, Thanks a lot, You have put it in a nic

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

ke to hear from others who are knowledgeable about such things. Thanks, Paul On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" <pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>> wrote: On 7/31/17 11:26 AM, Prakash K wrote: What would be the behavior

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

On 7/31/17 11:26 AM, Prakash K wrote: What would be the behavior of UA when 200 OK received which is not matching the dialog "200OK received by UA with different Call-id which is not in context" I see the following snippet in RFC 3261 which says UA should create dialog. Wont this end up in

Re: [Sip-implementors] Contact header URI comaprision

h the new one, and hence there should only be one current contact - the new one. Thanks, Paul Can you please clarify? BR/// Rakesh Kumar Mohanty On Mon, Jul 17, 2017 at 10:13 PM, Paul Kyzivat <pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>> wrote:

Re: [Sip-implementors] Contact header URI comaprision

On 7/17/17 11:08 AM, Rakesh wrote: Hi Expert, Now I got the full picture for the problem. SIP Registrar behavior for the URI contact matching 1) REGISTER request with belwo contact send to Registrar Contact:

Re: [Sip-implementors] Contact header URI comaprision

On 7/14/17 3:53 AM, Rakesh wrote: Hi Expert, I am facing an issue on which the contact URI comparison has happened and it fails due to the TRC parameter not in order which I guess so far. Contact: "" Contact: ""

Re: [Sip-implementors] SDP answer with c=0.0.0.0 and a=sendrecv behavior

Comment at end On 7/7/17 11:17 AM, Sourav Dhar Chaudhuri wrote: Hi, There is a B2B sitting between A (Caller) and B ( callee) 1) A has sent INVITE without SDP towards B 2)B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0 o=- 16408314 16408314

Re: [Sip-implementors] Is it possible to fork early media?

On 7/5/17 10:18 PM, Dale R. Worley wrote: In a perfect world, the caller would test each media stream for whether it is "silent", and then all of those that are not silent would be mixed for presentation to the user. (Humans can usually parse multiple audio sources.) If an early dialog

Re: [Sip-implementors] Is it possible to fork early media?

On 7/4/17 12:55 PM, Rodrigo Pimenta Carvalho wrote: Hi. I still have to study and learn about forking calls via SIP. But, before starting my studies, I would like to know if it is possible to do fork + early media. For example, when user U1 calls and his call is forked (parallel fork) to

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

On 6/28/17 1:11 AM, Parveen Aggarwal wrote: Dear Expert, Is it valid to send deRegister request i.e. REGISTER with expires=0 before receiving final response for previous registration request i.e. REGISTER with expires >0 ? As per RFC 3261, It is mentioned for new REGISTER request only UAs

Re: [Sip-implementors] Handling of message cross over between 200OK(INVITE) and 200OK(PRACK)

Dinoop, On 5/26/17 4:50 AM, Dinoop wrote: Thanks Worley and Paul, My scenario is, UAC B2BUA UaB | 1:INVITE(SDP) || +--->|| | 2:100[INV] |

Re: [Sip-implementors] Handling of message cross over between 200OK(INVITE) and 200OK(PRACK)

On 5/24/17 2:53 AM, Dinoop wrote: Hi, How can a B2BUA handle message crossing of 200OK(invite) over 200OK(PRACK)? Is it a correct approach for the implementation to reject the 200OK(INVITE) until it receives PRACK response? I have gone through the RFC 6337, unfortunately nothing is mentioned

Re: [Sip-implementors] Duplicate RTP streams with same source IP address and Port number

Ramesh, On 5/22/17 3:00 PM, Ramesh Kuppili wrote: SIP Gurus, I have a situation where I am receiving multiple RTP stream from the same IP address and port number. But with different SSRC. The media in the both streams is the same (audio, more precisely ringback tone). How should I handle

Re: [Sip-implementors] race_condition

On 4/4/17 1:28 PM, Brett Tate wrote: Please help to understand situation described as " Race Condition" ! See RFC 5407. And if that doesn't give you the answer, then please explain your problem in some detail. Thanks, Paul ___

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

On 3/10/17 2:49 PM, Dale R. Worley wrote: Puneet Kumar writes: 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? If not then please point out RFC section which blocks a UA from doing

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

On 1/19/17 12:05 PM, Brett Tate wrote: 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

  1   2   3   4   5   6   7   8   9   10   >