Re: [Sip-implementors] SIP REGISTRTION INFO

Rakesh, You don't say, at step 8, what code is the UAS using to reject the new register request? Thanks, Paul On 1/6/17 7:50 AM, Rakesh wrote: Hi Expert, My understanding is this please correct if I am wrong, Step 1) UE sent REGISTER with CSequence Number: 1804289384 and

Re: [Sip-implementors] SIP REGISTRTION INFO

On 1/6/17 12:52 PM, Rakesh wrote: Hi Paul, It's 401 unauthorized error. Do you then use the challenge to generate new credentials for a retry, just as you did in the first round? Thanks, Paul On 06-Jan-2017 11:15 PM, "Paul Kyzivat" <pkyzi...@alum.mit.edu

Re: [Sip-implementors] SIP REGISTRTION INFO

Rakesh, You don't say, at step 8, what code is the UAS using to reject the new register request? Thanks, Paul On 1/6/17 7:50 AM, Rakesh wrote: Hi Expert, My understanding is this please correct if I am wrong, Step 1) UE sent REGISTER with CSequence Number: 1804289384 and

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

On 1/4/17 7:42 AM, Vimal Tewari wrote: RFC 3262 says (in the Introduction part): PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. *If this were not

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

On 1/3/17 2:08 AM, Varadhan Work wrote: Hello, Is it legal to have SIP domain name in SIP packet with only one single part without top level domain name ? In general domain name syntax *A domain name consists of one or more parts, technically called labels, that are conventionally

Re: [Sip-implementors] m:inactive in SDP offer

On 11/23/16 7:14 AM, Aman wrote: Hi Experts, We have a MGCP gateway responding 200 without any media attribute ('sendrecv' is the default) to the offer in the CRCX is sent with 'Mode: inactive'. *Call AgentMedia Gateway* CRCX(Mode: inactive) --->

Re: [Sip-implementors] SIP-URI Without Userinfo

On 11/7/16 4:49 AM, Adnan Aziz wrote: Hello Everyone, According to the rfc3261, the userinfo in the sip-uri is optional. If there is no userinfo part then there should not be any "@" sign as well in the sip-uri. I have couple of questions 1) If I am receiving a sip request without userinfo

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

Alex, On 11/4/16 12:31 AM, Alex Balashov wrote: Hi, As far as I can tell from the RFC 3261 ABNF, it is permitted to put SEMI and EQUAL in the username of a URI, but it has no semantic validity. Why do you say this has no semantic validity? The owner of the domain determines the semantics of

Re: [Sip-implementors] DTMF digits dupplicate issue

On 10/24/16 8:19 PM, Kapila wrote: On Tue, Oct 25, 2016 at 2:04 AM, Dale R. Worley wrote: Kapila writes: Is it allowed to transmit dtmf in inband audio as well as in dynamic payload type ? As far as I know, it is valid to send DTMF in-band as

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

On 10/12/16 12:40 PM, Brett Tate wrote: 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

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

On 10/12/16 8:16 AM, Gagandeep Singh wrote: Considering below scenario. (Please view in fixed-width font) UAC B2BUA1 B2BUA2 UAS |--INVITE->| | | | |--INVITE->| | |

Re: [Sip-implementors] Video Codec presentation in SDP-Offer/Answer

On 10/6/16 12:40 AM, Sachin Rastogi wrote: Hi Everyone, I have a User Agent, which can decode H.264-HP as well as H.264-BP. But it can encode only H.264 BP. So how should I share my offer in SDP Option 1 : m=video 2300 RTP/AVP 100 109 a=rtpmap:100 H264/9 a=fmtp:100

Re: [Sip-implementors] Arbitrary Via parameters

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 <mailto:pkyzi...@alum.mit.edu&g

Re: [Sip-implementors] Arbitrary Via parameters

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

Re: [Sip-implementors] Arbitrary Via parameters

On 9/30/16 12:39 PM, Alex Balashov wrote: Hi, I have a proxy implementation that adds a custom parameter to Via that is not within the commonly seen subset of "maddr", "ttl", "received", or "branch". It adds a parameter called "i", whose value is alphanumeric (think hex nibbles). I can't find

Re: [Sip-implementors] No RBT Fixed IMS CPE's

I'm not certain, but I suspect there is a misunderstanding here. The presence of SDP in a 1xx response permits the establishment of a media stream from the UAC to the UAS. It doesn't matter what sort of 18x it appears in - 180, 183, etc. It really has *nothing* to do with rendering ringback.

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

On 9/14/16 12:00 PM, Harrison, Jason, Vodafone UK wrote: Hi Dale and others who have responded, Thanks for the response; the UPDATE does not contain any SDP as it is just for a display update as the call is picked up on another phone What do you mean by "display update"? Are you changing the

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

On 9/14/16 7:05 AM, Harrison, Jason, Vodafone UK wrote: Hi, I have an issue and I can't identify if the behaviour is wrong: Here is a working call Provider Customer SBCSBC INVITE (SDP offer)--> <--100 Trying <--180 Ringing (SDP answer) PRACK --> <-- 200OK

Re: [Sip-implementors] Multimedia messaging using MESSAGE method (SIP SIMPLE)

On 9/13/16 2:44 AM, Pratik Patel wrote: Hi All, Currently I am adding support of SIP SIMPLE for IM and Presence. I have use "page-mode" for implementation of IM (RFC-3428). So, I am able to send only text-messages. So, I want to know that , Is there any way to send multimedia files like image,

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

I agree with Brett on all points. If you are writing a test suite for sip, then I think you should reject the invite. 481 seems like a reasonable response, but may not be sufficient to indicate the problem. OTOH, if you are simply trying to build a system that maximally interoperates with

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

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 U

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

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

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

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

[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

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

On 8/8/16 4:32 PM, Manolis Katsidoniotis wrote: Thanks for the fast answer! I've been unable to find an SDP version reference though... For instance this looks very vague ... Therefore, session parameters in the offer/answer exchange SHOULD be as close to those in the pre-re-INVITE state

Re: [Sip-implementors] - RFC 6337 Section 5.1 - reINVITE without sdp

On 8/2/16 4:04 PM, Pavan Pandey wrote: Hi All, In the below mentioned scenario, UA supports advanced Video, AVPF and SAVPF features. UAC1 initiates an audio call with UA and subsequently sends reINVITE without sdp. As per RFC 6337 section 5.1 understanding, UA should make an offer with all

Re: [Sip-implementors] Non-dialog NOTIFY for a SUBSCRIPTION with "Event: presence"

On 7/26/16 1:41 PM, My Gmail wrote: This is not possible. Please refer RFC 6665, section 4.1.3: It *is possible*. (And it is *done*.) But it is contrary to 6665, and (arguably) to 3265. Thanks, Paul Thanks and Regards Dheeraj Kumar Sent from iPhone On 26-Jul-2016, at

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

On 7/25/16 7:38 AM, Brett Tate wrote: My doubt in RFC 3312 is about 183 response for a re-INVITE. Do user-agents respond with 18x for a re-INVITE and accept 183 in re-INVITE? How would you *not* accept one if it is received? You must do *something*. You *must* minimally wait for a final

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

On 7/25/16 6:25 AM, Brett Tate wrote: 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

Re: [Sip-implementors] Handoff

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

Re: [Sip-implementors] [QUAR] Your message to discussion awaits moderator approval

On 6/28/16 10:46 AM, Zuñiga, Guillermo wrote: Hi Fellows, could you help me know what means What means Message body is too big: 229288 bytes with a limit of 150 KB Do you *really* have a *sip* message with a body of size 229288??? What is it? MESSAGE? While SIP doesn't have any builtin

[Sip-implementors] Anybody have an implementation of RFC5626 (SIP Outbound)?

I'm interested in talking with anybody that has experience implementing SIP Outbound. You can contact me privately if you wish. I'm working on plans for a system that is planning to use outbound, and I want to know of issues that others have encountered. Thanks, Paul

Re: [Sip-implementors] Media and Signaling IP

On 6/15/16 11:14 AM, dheeraj kumar wrote: Hi , Signalling and media IP can be same or different. This information is regarding network side. Usually same IP for media and signalling is difficult to manage on the network side in this case we need to segregate the IP address of the basis of ports

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

On 5/4/16 10:38 AM, Brett Tate wrote: 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

Re: [Sip-implementors] SIPS downgraded to SIP

On 4/13/16 7:39 AM, Arun Arora wrote: Hi All, I am curious, if a secure session (SIPS) establishment starts and there are two proxies b/w UAC and UAS path which done support SIPS, what will happen to session establishment? Will the communication downgrade to SIP (non-secure) or the session

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

On 3/20/16 12:26 PM, Neelakantan, Neel wrote: Please review RFC 3261. This is addressed in it. The provisional response must be forwarded by proxy to the UAC. The answer ( 200 OK) can be from any of the UAS and there is no way of Proxy knowing it. The UAC should be prepared to handle forked

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

On 3/15/16 8:03 AM, ankur bansal wrote: Hi Paul Please explain more about what you are asserting for TLS. It looks wrong to me, but I'm not sure I understand what you are trying to say. I was trying to point to RFC 5923 which provides provision to reuse same TLS connection not only for

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

On 3/14/16 3:32 PM, Dale R. Worley wrote: "xaled" writes: A client originates a session over TCP connection to proxy1 after having it resolved as top priority outbound proxy from preconfigured edge.test.com domain. Proxy 1 sends 200 Ok response with following Record-Route header:

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

On 3/14/16 8:07 AM, ankur bansal wrote: Hi There is no recommendation for using exisiting TCP connection for in-dialog Sip requests. As MTU for PRACK/BYE can be smaller ,so can be send over UDP also . But for TLS recommendation is there to reuse same connection ,even for request coming from

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

On 3/10/16 6:52 AM, Brett Tate wrote: 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

Re: [Sip-implementors] authentication-info header

at header field and continue processing the message." -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat Sent: Tuesday, February 16, 2016 12:39 PM To: sip-implementors@lists.cs.colu

Re: [Sip-implementors] authentication-info header

On 2/16/16 11:19 AM, Jing Jiang wrote: Recently, we saw a case that a server (Asterisk) sent our client an authentication-info header in its "bye" message, but our SIP device is just a client and never challenges the server. Our client doesn't expect this header so the "bye" request was

Re: [Sip-implementors] Use of "lr" param with a value?

This is all speculation. You will have to ask the developer of the offending implementation for an explanation. Thanks, Paul On 2/10/16 8:09 PM, Alex Balashov wrote: On 02/10/2016 02:21 PM, Paul Kyzivat wrote: Charitably, it may have been an attempt to apply Postel's Maxim

Re: [Sip-implementors] Sequential requests that bypass RR proxy

On 2/9/16 8:58 PM, Alex Balashov wrote: Hi, 1. I set up a call between two UAs through a proxy: UAC A > Proxy P1 -> UAS B 2. P1 inserts a Record-Route header indicating that sequential requests should be directed through it. 3. UAS B does not follow Record-Route properly and,

[Sip-implementors] Use of "lr" param with a value?

[Robert - question here for you] On 2/10/16 11:20 AM, Alex Balashov wrote: ‎Thanks, Paul. FWIW, B is strictly a UA, not a part-time proxy. The implementors of A have traced the problem to P's attachment of a value to the ;lr parameter in the RR: Record-Route:

Re: [Sip-implementors] Use of "lr" param with a value?

On 2/10/16 1:58 PM, Alex Balashov wrote: ‎Fair enough. But it seems a bit schizophrenic of this particular implementation to apply the 'lr" grammar strictly, but then consume the route set anyway (as indicated by improper inclusion of Route headers from B in the BYE), albeit not actually

Re: [Sip-implementors] Use of "lr" param with a value?

On 2/10/16 1:38 PM, Alex Balashov wrote: ‎From a methodological point of view, I am curious: If the 'lr' parameter has a value assignment, is UA B truly justified in ignoring the route set categorically? Or is that one of those things where behaviour for improperly formed tokens is

Re: [Sip-implementors] Serach order for multiple Diversion headers

On 2/9/16 4:52 AM, Roger Wiklund wrote: Hi If a request contains multiple Diversion headers, can one assume that the topmost is used, or is this up to the application? I'm looking for a MUST in one of the RFCs. You won't find one. Note that the Diversion header was an unsuccessful effort.

Re: [Sip-implementors] dialog termination

On 2/8/16 10:38 AM, Manolis Katsidoniotis wrote: Hello implementors I have a flow where "re-INVITE" with new offer, receives a 200OK with invalid answer. Should A side send ACK and BYE or just BYE? You MUST send ACK. Then you MAY send BYE if you feel you must. Or you could try to take other

Re: [Sip-implementors] RE-INVITE QUESTION

On 2/4/16 11:11 AM, Roman Romenskyi wrote: Hello, If anyone have an idea: UAC sends RE-INVITE, than send CANCEL request, is this situation is correct? Because dialog state is connected, and 200 OK for a first INVITE are sent. How We should process it? Please point me to rfc. CANCEL has

Re: [Sip-implementors] RFC 3840 updating RFC 3261

On 2/3/16 11:23 AM, Sheldon Patry wrote: hello, By reviewing RFCs I came with that question: RFC 3840, section 9 says: The following production updates the one in RFC 3261 [1 ] for contact-params:

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

Just to elaborate - 3pcc is one of my touch stones. When considering any O/A behavior I always ask the question: will this do the right thing if 3pcc is being used? And remember, the receiver of an offerless invite doesn't *know* if 3pcc is in use - it had better assume that it might be,

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

On 1/19/16 12:40 AM, Basu Chikkalli wrote: We have following two RFC references: Rfc3261 Sect 14.2 UAS Behaviour 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

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

questions later when they can't interoperate with you. Thanks, Paul Thanks for clarifying. - ramesh On 1/19/2016 8:39 PM, Paul Kyzivat wrote: On 1/19/16 12:40 AM, Basu Chikkalli wrote: We have following two RFC references: Rfc3261 Sect 14.2 UAS Behaviour A UAS

Re: [Sip-implementors] CLARIFICATION NEEDED ON SIP RE-DIRECTION & CONTACT HEADER

Karthik, I'm having trouble understanding the motivation for your questions. Some of them are basic stuff, that can be answered by a reading of RFC3261. Are you new to sip, trying to get the fundamentals here? Some of your other questions seem to be asking about *why* sip is the way it is.

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

On 1/5/16 10:48 AM, Brett Tate wrote: 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. Yes. However, creating a dialog solely for the purpose of conveying MESSAGE messages

Re: [Sip-implementors] SIP

On 12/31/15 4:38 PM, Dale R. Worley wrote: "Karthik.v" writes: 1) You meant to say that Registration is creating a dialog (dialog-id) but there is no reason for using it. Am I correct ? A registration does *not* create a dialog, but the stream of REGISTER messages

Re: [Sip-implementors] Some Queries(Doubts) in SIP

On 12/30/15 5:17 AM, Vivek Batra wrote: 3. Since it is optional and not sent in the REGISTER request, I would like to see registrar to simply return the present bindings. However not surprise for me if it's been rejected with 400 Bad Request and can be seen in many practical implementations.

Re: [Sip-implementors] Some Queries(Doubts) in SIP

On 12/30/15 1:32 AM, Karthik.v wrote: Hi all, I have some list of queries on sip , It sounds like you are just getting started with sip. If you haven't already, you would do well to read one or more of the introductory books. 1) Please state a real time scenario where multiple

Re: [Sip-implementors] Offer Answer Model During Early Dialog

I agree with the other responses to this query. See RFC6337 for more detail. Thanks, Paul On 12/18/15 7:45 AM, Sourav Dhar Chaudhuri wrote: Hi, Please refer the diagram below Callflow diagram 1) A -INVITE [ Support: 100 rel] without SDP

Re: [Sip-implementors] Offer Answer Model During Early Dialog

December 2015 9:17 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: I agree with the other responses to this query. See RFC6337 for more detail. Thanks, Paul On 12/18/15 7:45 AM, Sourav Dhar Chaudhuri wrote: > Hi, Please refer the diagram below Callflow diagram

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

On 11/13/15 6:58 AM, Arun Arora wrote: Hi all, Is their any specific length of To/ From header defined by the standard (I guess not, but still would like to know other’s views) My usual answer to this is that the length of any one header field in the message is bounded by the size of the

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

within the buffer. Thanks, Paul Thanks, Arun On 13/11/15, 8:25 PM, "Paul Kyzivat" <sip-implementors-boun...@lists.cs.columbia.edu on behalf of pkyzi...@alum.mit.edu> wrote: On 11/13/15 6:58 AM, Arun Arora wrote: Hi all, Is their any specific length of

Re: [Sip-implementors] Help: UE behaviour corresponding to different registration events received in Notify

Rohit, As far as the basic sip standards there is *no* dependency between registration and dialogs. So in general the ending of a registration need have no impact on any dialogs active at that time. But the environment you operate within may attach some added constraints. A couple of cases

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

On 10/20/15 12:50 PM, Anand Konji wrote: Generally (but not limited to ), - 407 proxy responses for messages sent to SIP clients. - 401 responses for messages sent to SIP servers. Not quite. A 407 can be returned for any request if it happens to go through a proxy that cares. And a 401 can

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

On 10/20/15 8:37 AM, Tuxic Geek wrote: Hello Anand, You are totally right, although I have a confusion here about what proxy is challenging me with the 407 response code? I mean by the word proxy what does the server mean? Does it mean Media Proxy? It means sip proxy as defined in rfc3261.

Re: [Sip-implementors] offer-questions.

I'm going to differ with Vivek to some extent. See inline below. In any case, I suggest reading RFC6337. On 10/19/15 2:21 AM, Talwar, Vivek (Nokia - IN/Noida) wrote: Hi Sipuser, Please find the responses as per scenario: 1. Its valid as terminating endpoint is mentioning its preferences

Re: [Sip-implementors] offer-questions.

Trimming On 10/19/15 1:12 PM, K sipuser wrote: - INVITE with codec1,codec2,codec3 - 183 received with codec2. - Update *send* with codec4 - In early dialog state is this valid? How is this different from (2)? The only difference I see is *received* vs. *sent*. But every message received must

Re: [Sip-implementors] Redirection of Call without REFER

On 10/12/15 4:06 AM, Mayank Gupta wrote: Thanks a lot Anand & Pranav. Pranav - Call needs to be redirected after RTP is established at both ends. So 3XX can't be used. Anand - RFCs supported by my SIP stack - 3161, 3261, 3262, 3264, 5009, 3311, 3325, 3960, 4244, 4240, 4566. Unfortunately,

Re: [Sip-implementors] Remote-party-id in reinvite

elay in the middle hiding the change from you. Thanks, Paul In this case how to establish media path between sip-dialer with agent phone. Sorry if I'm not making it clear..will explain further if required. Thank you... Regards Mahu Original message From: Paul Kyz

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

On 10/5/15 7:23 PM, Maxim Sobolev wrote: David, IMHO that "same ordering" clause refers to the "header values" (i.e. individual "via" lines), not to the order of parameters within ONE header value. Order of values is important, because it defines your return path. Which is why the clause is

Re: [Sip-implementors] Remote-party-id in reinvite

On 10/5/15 8:43 AM, Mahudeswaran A wrote: Hello All, We are facing a situation and looking for insights on how to handle the scenario 1.uac--(invite/sdp)>uas 2.uac<(100 trying)---uas 3.uac<(200ok/sdp)uas

Re: [Sip-implementors] SIPREC and call transfer without REFER

On 10/2/15 8:42 AM, Roger Wiklund wrote: Hi list! We are testing out SIPREC in our Acme SBCs. The goal is to be "PBX neutral" for a lack of a better word. We are using Verba as SRS. Basic incoming and outgoing calls work fine. SRC sends SIPREC INVITE to SRS with metadata containing A och B

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

One more thing... On 9/23/15 3:23 AM, Eize Slange wrote: To answer your questions/comments with respect to my given scenario: - I also think that the first INVITE isn't lost but already being processed inside the SIP-stack. This because it's a lab network and so lost packet is rare...

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

On 9/22/15 9:31 AM, Eize Slange wrote: Hi all, We've a situation here that happens under high load and so things are running 'out of sync' / being queued / delayed responses etc. The end result is that the call is being dropped due to 500 response, which is unwanted. Different SIP-stacks are

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

I was apparently writing my reply in parallel with Brett. And we have arrived at essentially the same conclusion. Thanks, Paul On 9/22/15 10:30 AM, Brett Tate wrote: Consider SIP-dialog between UA1 & UA2. UA1 sends reINVITE to UA2, and immediately also an in-dialog UPDATE (to

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

I just noticed this thread. So I'm jumping in where it seems to make sense. Note that 3261 and friends are *not* very clear about this. RFC6337 tried to clarify the original intent, without being normative. (In retrospect it would probably have been better to make a normative update.) There

Re: [Sip-implementors] Two provisional responses in one dialog: 180 Ringing and 183 Session Progress

On 8/30/15 3:18 PM, Franz Edler wrote: Dear SIP-ISUP experts, I don't know ISUP, so I'll ask some followup questions. we have a nasty situation in case of interworking SIP to ISUP. The INVITE request is mapped to ISUP/IAM, that's as expected. But then on the ISUP side we have a colored

Re: [Sip-implementors] Two provisional responses in one dialog: 180 Ringing and 183 Session Progress

On 8/31/15 12:41 PM, Franz Edler wrote: The 180 doesn't mean that you should generate ringback instead of playing in-band ringback. You should treat the 180 as meaning: generate ringback if you are not receiving in-band media. O.k. understood, but the " ... if you are not receiving in-band

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

Brett, I'm not aware of anywhere that *says* anything about the (in)significance of the order. IMO, based on the overall philosophy of 3261 I would say that the ordering must be insignificant. Thanks, Paul On 8/28/15 1:36 PM, Brett Tate wrote: Hi, RFC 3261 section 7.3.1

Re: [Sip-implementors] SIP Reinvite after T38 Negotitaion

It isn't entirely clear what the fundamental question is. The original question seems to be concerned with whether it is allowed to go back to audio after having previously switched to fax. But this is mixed up with details of the SDP involved. IIUC, the scenario involves *3* O/A exchanges:

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

I generally agree with what Tarun is saying, but have one clarification On 7/22/15 1:39 PM, Tarun2 Gupta wrote: Hi Please refer Section 7.2 of RFC 4028. If the UAS did not include a SE header in 200 OK response, it means that it does not want / support session expiration. In this case, UAC

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

, not 408. Sorry. Thanks, Paul -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, July 22, 2015 1:52 PM To: sip-implementors@lists.cs.columbia.edu

Re: [Sip-implementors] Offer answer model.... Updated

is generally a pathway to a suboptimal experience. Thanks, Paul Does RFC says anything or is it implementation dependent behavior?? Thanks, On Wed, Jun 24, 2015 at 12:04 AM, Paul Kyzivat pkyzi...@alum.mit.edu wrote: I saw this after replying to the prior message. But I don't see

Re: [Sip-implementors] Multiple telephone-event in m line

On 6/24/15 9:28 AM, Gaurav Khare wrote: Hi, I have a SIP client sending below SDP ... m=audio 8178 RTP/AVP 96 97 98 99 100 a=rtpmap:96 AMR-NB/8000 a=fmtp:96 mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0 a=rtpmap:97 AMR-WB/16000 a=fmtp:97

Re: [Sip-implementors] Offer answer model

On 6/23/15 9:13 AM, isshed wrote: I seem to have made a career for myself discussing questions like this! Hi All, Below is the scenario.. UAC1UAC2 1)-INVITE (a=sendrecv)-

Re: [Sip-implementors] Offer answer model.... Updated

I saw this after replying to the prior message. But I don't see anything here that alters my reply. Thanks, Paul On 6/23/15 9:16 AM, isshed wrote: Hi All, Below is the scenario.. UAC1UAC2

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

On 6/11/15 10:28 AM, Roger Wiklund wrote: Is this assumption correct: If UAC sends 100rel required, then UAC controls PRACK. If UAS sends 100rel supported, then UAS controls PRACK by sending 100rel required with proper RSeq? If that's correct I think the PBX is the problem here by sending

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

On 6/3/15 3:13 AM, isshed wrote: Hi All, Below is the scenario.. UAC1UAC2 1)-INVITE (a=sendrecv)- 2)-200-OK(a=recvpnly)-

Re: [Sip-implementors] When Does RTP should start flowing after 18x or 200OK/ACK

Regards, Ambrish On Fri, May 29, 2015 at 10:37 PM, Paul Kyzivat pkyzi...@alum.mit.edu mailto:pkyzi...@alum.mit.edu wrote: On 5/29/15 12:11 PM, Ambrish Kumar wrote: Dear Team, I am working on Lawful interception and integrating our IMS nodes (SBC) with LEA. We

Re: [Sip-implementors] When Does RTP should start flowing after 18x or 200OK/ACK

On 5/29/15 12:11 PM, Ambrish Kumar wrote: Dear Team, I am working on Lawful interception and integrating our IMS nodes (SBC) with LEA. We have got a very unusual ask form IB/RAW where they want to listen the RTP flow before call is actually answered by “B” We need your help and confirmation

Re: [Sip-implementors] Q.850 includes in Proviosional response

You don't say what happens *after* they send this 183. That doesn't terminate the dialog - there still must be some final response. Does the final response accurately reflect the distinction between busy, invalid, etc.? AFAICT this doesn't violate anything, so it is *technically* valid. But,

Re: [Sip-implementors] Q.850 includes in Proviosional response

...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat Sent: May-28-15 10:29 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Q.850 includes in Proviosional response You don't say what happens *after* they send this 183. That doesn't terminate the dialog - there still must

Re: [Sip-implementors] What does identical mean?

I should have noticed Dale's reply before writing my own that says the same thing. Thanks, Paul On 5/26/15 7:07 AM, Dale R. Worley wrote: Ren Xin nathanren...@gmail.com writes: Our product actually compare the newly received SDP with previous one and if they are not

Re: [Sip-implementors] What does identical mean?

are not byte-by-byte identical, you act as if the version was updated even if it was not, then ISTM the only harm that can arise is that you might succeed in interoperating. But it is your choice. Thanks, Paul On Mon, May 25, 2015 at 6:31 PM, Paul Kyzivat pkyzi...@alum.mit.edu

Re: [Sip-implementors] What does identical mean?

On 5/25/15 6:45 AM, Ren Xin wrote: Hey, According to RFC 3264 par.7 If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has

Re: [Sip-implementors] SIP Call on hold - Reinvite Session Attribute Vs Media Attribute

On 5/12/15 9:35 AM, Sylvester, Prasanth (Nokia - IN/Mumbai) wrote: Hi Team, I've a small doubt. I have a working call where A party is talking to B party. B party putts the call on hold, however I see Session Attribute with a value SendOnly. Mostly I've seen it coming in Media Attribute.

Re: [Sip-implementors] Q regarding call transfer and P-Asserted-Identity

ISTM that this is a value judgement on the part of the PBX - exactly how it thinks its transfer feature should work. In particular, does it *want* to disclose to the caller that a transfer has occurred. Thanks, Paul On 5/12/15 11:55 AM, ankur bansal wrote: Hi Roger Cisco PBX

Re: [Sip-implementors] URI value mandatory for Alert-Info?

On 5/11/15 9:12 PM, Alex Balashov wrote: Hello, The ABNF grammar for Alert-Info is: Alert-Info = Alert-Info HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) I have an application that seems to utilise just a generic-param

Re: [Sip-implementors] URI value mandatory for Alert-Info?

. Thanks, Paul Thanks, Jim -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat Sent: Tuesday, May 12, 2015 9:12 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip

<    1   2   3   4   5   6   7   8   9   10   >