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 ex
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 neces
have 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:
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.)
B
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
__
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
On
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
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 U
-
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
O
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
a=rtpmap:105 telephone-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.
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 fai
rying 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
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:
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 / "-" / "." / "!" /
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 imp
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 , we
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 rig
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 RFC
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 ever
understanding, 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
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 fine
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 c
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:
Hello
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 s
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 lo
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 recognized
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 use
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 ne
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 get
should 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:pk
affect the Route 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>>
@es8.example.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>&
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
x.x.x.x:50
address 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
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 c
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
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 no
t-ID:
Otherwise 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
app
e limit.
Thanks,
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 Reques
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 MESSA
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
e help.
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 t
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 )
CRL
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 me
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 *wrong*
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
le
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
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)
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
, if a
payload 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.
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
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.
SIP/
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
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
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 q
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
De
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
URI
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 co
,
Paul
On Mon, Jul 16, 2018 at 01:56:34PM -0400, Alex Balashov wrote:
Oh, yes — they're different dialogs, for sure. I just wasn't sure if
that would nevertheless pose a problem for some low-budget UAs.
On Mon, Jul 16, 2018 at 01:47:32PM -0400, Paul Kyzivat wrote:
On 7/16/18 1:1
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 of
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 m
need to be judged 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 i
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 a
On 7/3/18 3:53 AM, Alex Balashov wrote:
No, it's not illegal to retry a call to the same gateway (in case of 6xx
response).
Nor is it illegal to reject it. :-)
My experience in an applied sense with SSTs (SIP Session Timers) is that they
are poorly supported, seemingly due to all the state-ke
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, U
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 wrote:
Abhishek,
On 5/23/18 7:15 AM, Abhishek wrote:
Hello,
SS7 Switch —> Gateway Switch —> SIP SBC
Call flow is as men
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
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 wrote:
On 3/25/18 5:26
On 3/25/18 5:26 PM, Alex Balashov wrote:
Hi,
Are 407 challenges meant to have a To tag? If so, I can't find the
rationale in 3261. Any pointers would be appreciated.
(working from memory)
An argument against to-tag in 407 would presumably apply equally to any
3xx, 4xx, 5xx, or 6xx. One could
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 (code
On 2/9/18 5:18 AM, Alexey wrote:
Good morning.
I have an issue for following call flow :
MGC 8 -> pjsip
> INVITE
< OK
>ACK
...established rtp g711a...
< re-INVITE T.38 attempt to switch to t.38
> 100
>488 Not acceptable here
After this ACK my provider required me send re-invite with G711
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 >
< 10
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 UAC*
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 IN
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 subtl
(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 applied
e?
Br,
Ivo
On Tue, Oct 10, 2017 at 8:37 PM, Paul Kyzivat <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
scenario.
We have th
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 to
On 10/6/17 10:29 PM, Dale R. Worley wrote:
Paul Kyzivat 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 expiration of
the registration without
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 dialog
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, if
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 F
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 i
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
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
*>>* --
#x27;re in cohoots with the thing that's breaking the protocol,
you know 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
n from 3261 and 6026.
I'd like to hear from others who are knowledgeable about such things.
Thanks,
Paul
On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" <mailto:pkyzi...@alum.mit.edu>> wrote:
On 7/31/17 11:26 AM, Prakash K wrote:
What would be the b
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 ack
hat
they are both current. Yet they compare equal so the registrar should
have replaced the old one with 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
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:
"";expires=7200
2) Registrar sent 200OK with below contact
Contact:
"";expires=
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: ""
I saw in RFC 3261 19.1.4 URI Comparison
URI uri-parameter components are c
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
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 receive
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
u
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 MUS
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] |
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 a
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 this
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
___
S
1 - 100 of 1159 matches
Mail list logo
