There is a revision underway on SDP. The a=quality attribute has always
been underspecified. We would like to tighten up the specification, but
do so in a backward compatible way with existing usage if possible. So
far we have not identified any usage of it. If not, we will probably
leave the
that. But the callerpref stuff is all
optional, and frankly I'm not aware of *any* implementation that honors
no-fork. :-(
Thanks,
Paul
Thanks,
Sourav
On Tuesday, 5 May 2015 6:53 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote:
On 5/5/15 4:21 AM, Sourav Dhar Chaudhuri wrote:
Hi Paul
to the extent I described, is not optional there. It would get
tiresome for every sip document to emphasize every mandatory feature of
3261 that must be supported.
Thanks,
Paul
Thanks,
Sourav
On Monday, 4 May 2015 9:38 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote:
On 5/4/15 10
20, 2015 at 4:42 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi...@alum.mit.edu wrote:
Anish,
It is a little hard to follow you, but I think you still aren't getting
how it works.
- If X offers two codecs, and Y answers with both of those,
then there is no choice of codec. Either
On 2/28/15 8:05 PM, brez wrote:
Hi Paul,
Please see inline..
On 2/28/2015 10:58 PM, Paul Kyzivat wrote:
On 2/28/15 3:36 PM, brez wrote:
Hello,
Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates
On 2/28/15 3:36 PM, brez wrote:
Hello,
Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates resources (ports) for a non-existent media session?
In principle you can send an initial offer with SDP that
On 2/27/15 8:28 AM, VISHAL GOYAL wrote:
Hi Experts,
As we know, The range of q parameter in SIP is between 0 to 1.
Is there any exact limit on the decimal places ?
From 3261:
qvalue = ( 0 [ . 0*3DIGIT ] )
/ ( 1 [ . 0*3(0) ] )
for example : Is q=0.87654 valid ?
On 2/20/15 10:51 AM, a...@ag-projects.com wrote:
On 20 Feb 2015, at 09:50, Sreejith Sadaasivan sreejith_sadasi...@yahoo.com
wrote:
Hi All,
I have a doubt on presence subscription of a buddy.
1) whether it is always mandatory to subscribe to a buddy with SUBSCRIBE
message to retrieve the
On 2/11/15 4:17 PM, rsw2111 wrote:
4028 is clear that the supported header in the initial INVITE indicates
whether or not refreshers are supported by the UAC. In this case, there is
no Supported header in the initial INVITE, so it can be assumed that the
A-side does not support refreshers. That
On 2/10/15 4:49 PM, rsw2111 wrote:
Hi,
I've been debating this with someone, and I'd appreciate some outside input.
below is the scenario:
A B
INVITE - with no supported header
--100
--18X
--200OK with no refresher/session-expires or min-se
ACK
--INVITE with
...@lists.cs.columbia.edu] On Behalf Of ext Paul
Kyzivat
Sent: Thursday, February 05, 2015 10:02 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] race conditions
On 2/5/15 2:49 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote:
Hi Team,
I've a situation,
Customer A - SBC01 (XYZ vendor
On 2/5/15 2:49 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote:
Hi Team,
I've a situation,
Customer A - SBC01 (XYZ vendor) - SBC02 (XYZ Vendor) - Core
Customer A sends an invite to SBC01, which reaches to Core. While Core sends a 200
OK before it reaches the Customer A, Customer A had
On 1/27/15 4:59 PM, Manolis Katsidoniotis wrote:
Hello
I would like to ask if anyone is familiar with multiple entries in Contact
field in INVITE and 200OK messages. I'm looking for implementation examples.
Not permitted.
So far I have seen many examples of multiple contact fields but in
On 1/22/15 5:54 AM, Brett Tate wrote:
What value the UAC should use in Expires header
on the next REGISTER refresh?
It can basically use whatever it wants. However if it wants to avoid
potentially receiving another 423, using a value = last Min-Expires would
be best.
I pragmatically agree
On 1/18/15 1:07 AM, Imran Saleem wrote:
Dear All,
Can someone please suggest the possible reason for this behavior.
In SBC The receiving side hooks on before calling party, the line is hold,
the re-Invite changes the stream mode to receive-only and that's why the IP
and port are 0.
What does
This seems like a subject that should be taken up on an ietf list.
sipcore is the likely one, though that is not the place to deal with the
generic uri syntax.
ISTM that this was a screwup when 3986 was published and didn't address
backward compatibility with sip URIs.
Thanks,
On 12/30/14 7:06 AM, isshed wrote:
Hi All,
Could anybody please let me know if the SIP option tags are case sensitive?
No, they are not.
RFC3261, section 7.3.1:
When comparing header fields, field names are always case-
insensitive. Unless otherwise stated in the definition of a
misbehaviour or uas sent any 183sdp before.plz
share full call flow to understand uas behaviour in better way
Yes - if there is more to the call flow then we need to see it all to
really understand.
Thanks,
Paul
On Dec 4, 2014 10:45 PM, Paul Kyzivat pkyzi...@alum.mit.edu
On 12/4/14 2:20 AM, Tarun2 Gupta wrote:
Hi
Our implementation is clearing the call on receiving no SDP (answer) in 200 OK
for a ReINVITE with SDP (offer) sent. Is this (call clearing) the recommended
behavior?
I am not able to find any normative RFC references to support this. Can you
please
On 11/20/14 1:38 AM, Ambrish Kumar wrote:
Hi All,
We read the RFC 3966 and understood that the global number should be
prefixed with “+” and if it is not prefixed with “+” then it is considered
to be a local number and a phone-context is a MUST.
But the section 7.4 is a bit confusing to the
On 11/20/14 6:41 AM, Rajesh wrote:
Hi,
May I know whether it is fine if UA insert PAI header in the INVITE
message which it sends to a trusted network entity. I am analysing one
scenario where one of our network node gets a call from another trusted
node with From set to Anonymous and PAI
On 11/18/14 1:30 PM, Ilan Avner wrote:
Hi all,
We are now doing some WEB-RTC interop tests with Chrome Browser, we test both
Audio and Video, currently it looks like Chrome requires SAVPF and while using
Video Chrome also sends a lot of video retransmissions depending on the control
RTCP
On 11/5/14 7:05 AM, Brett Tate wrote:
But my newer question is even by sending BYE for this
flow A is not violating any RFC. Since from the booth
RFCs mentioned above the expected behavior mentioned
by Ankur is SHOULD way not in MUST. So A behavior
may not the be best one but also not a
than that (more than 12 years ago), so I wasn't involved in it. I
gave you my best understanding of why. At this point there is little
point is speculating why, because it it too firmly engrained to be changed.
On Fri, Oct 31, 2014 at 10:04 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi
On 10/31/14 12:27 PM, ankur bansal wrote:
Hi All
Why ACK is made separate transaction when 2xx is final response.Reasons
being given that TL is deleted on getting 2xx to be independant of
upperlayer whether its UA core or proxy core.but now after rfc 6026 came TL
not deleted on getting 2xx.then
On 10/30/14 2:11 AM, Mahudeswaran A wrote:
Hello All,
Is it possible to transfer a call without using SIP REFER.
Call path:
[uac]---[sip proxy][uas]
The SIP REFER is not supported in the above sip proxy. Is there a way to
achieve call transfer without using sip refer...
It
On 10/30/14 5:23 PM, Dale R. Worley wrote:
From: Paul Kyzivat pkyzi...@alum.mit.edu
I disagree here. UA B would be irresponsible if it created an INVITE
including a header field that it doesn't understand.
Why would it be irresponsible?
It's not UA B that's deciding to produce the INVITE
On 10/28/14 11:54 AM, Dale R. Worley wrote:
From: Sourav Dhar Chaudhuri sourav_mi...@yahoo.co.in
Actually my scenario is attended call transfer using REFER
method. So here I want to transfer an attended call using
REFER method. But the User agent B whom I want to send REFER
On 10/23/14 4:28 AM, Saúl Ibarra Corretgé wrote:
Thank you all for the comments!
Adding a c= line is not an actual problem, I just wanted to know if it was
necessary or not :-)
Out of curiosity, what purpose does it serve if a disabled stream? One can
surely add it back wen re-enablinkg it…
On 10/22/14 11:37 AM, Saúl Ibarra Corretgé wrote:
Hi all,
I recently ran into an intro issue with some unknown SIP device. My client uses
a per-stream SDP connection line, but when a stream is disabled (port set to 0)
the stream is just reduced to the m= line.
Technically I could put the
On 10/15/14 10:22 AM, Sourav Dhar Chaudhuri wrote:
Hi,
Can CRBT works without using Reliable Provisional Response ?
A INVITE (with SDP offer) B
A === 180 ringing (with SDP answer ) B
,
Paul
Regards,
Mustafa Aydın
NGN Services
Verscom Solutions
cid:image002.png@01CFD749.D928FC00
*From:*Vivek Talwar [mailto:vivek.tal...@globallogic.com]
*Sent:* Wednesday, October 15, 2014 6:31 PM
*To:* Mustafa AYDIN
*Cc:* Paul Kyzivat; sip-implementors@lists.cs.columbia.edu
*Subject
On 10/1/14 9:08 AM, Kumar, Puneet (Puneet) wrote:
Hi All,
Consider following use case:
UA1 Proxy UA2
SUBSCRIBE
--SUBSCRIBE-
--200---
---NOTIFY--
On 9/19/14 1:20 PM, Kchitiz Saxena wrote:
Hi Brett
There is no received parameter in the request. Below is the Via header I
can see in the pcap taken at UAS -
Note that the message, as received by the UAS, won't contain a
received parameter. The UAS itself adds this parameter, and then
a lot for your detailed response. You have answered all
my doubts.
I am really grateful for your email.
Thanks Regards,
Sourav Dhar Chaudhuri
On Tuesday, 5 August 2014 8:11 PM, Paul Kyzivat
pkyzi...@alum.mit.edu mailto:pkyzi...@alum.mit.edu wrote:
On 8/4/14 10
On 8/4/14 10:12 AM, Sourav Dhar Chaudhuri wrote:
Hi,
Is there any way when a answered call [ 200OK is already provided for
initial INVITE and ACK also sent] can be transferred without using REFER method?
If it is possible without REFER then please let me know required procedure.
More
be trusted. At this point it becomes an authorization
decision - is this requesting identity *authorized* to make this
request. That is a different sort of decision.
Thanks,
Paul
Thanks and Regards,
Sunil
Message: 2
Date: Sun, 20 Jul 2014 14:35:30 -0400
From: Paul
Sunil,
What do you mean by wrong?
This is used with transitive trust, so presumably you should trust the
sender to have asserted the correct identity of the sender.
Do you mean that this identity is not authorized to make the
subscription it is requesting? If so, then I guess the proper
On 7/14/14 7:47 PM, James Cloos wrote:
PK == Paul Kyzivat pkyzi...@alum.mit.edu writes:
PK If you give out only URIs with domain names, then that is what
PK clients should be using.
PK Only servers that are responsible for the domain are permitted to
PK translate those URIs.
Thanks
On 7/15/14 7:07 AM, Brett Tate wrote:
Can there be any case when CANCEL reached to UA2
before INVITE in case od UDP? because the 100 trying
can be sent by proxies as well.
Yes, 100 is sent hop by hop. But CANCEL is itself also hop by hop. So at
each hop the cancel is only sent if a 1xx has
On 7/13/14 8:46 PM, James Cloos wrote:
I've noticed that all of the fraud attempts which come to my advertized
SRV destinations use ip addresses for the To and From headers and for the
INVITE line.
My code to verify that INVITEd addresses are valid expects domain names
or hostnames, not ip
Kapoor
On Mon, Jul 14, 2014 at 7:02 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi...@alum.mit.edu wrote:
On 7/14/14 6:14 PM, NK wrote:
Dear All,
I have query regarding the Session version in SDP. I know if we
are making
any changes in SDP then from 183
Is is silly and inappropriate to assert the validity of
anonymous@anonymous.invalid, because there is no such domain. Hence
nobody is in a position to make such an assertion.
But it could be appropriate to assert sip:anonymous@somedomain. This
would presumably mean: this is from *some* valid
On 7/1/14 9:37 AM, Sourav Dhar Chaudhuri wrote:
Hi,
How can be determined that whether SIP REGISTER is for new registration or
reregistration by seeing the request.
You *can't* tell by examining the REGISTER.
And for the most part it doesn't matter.
It seems that in case if the CSeq
to
Authorization implementation for reregistration.
I don't understand. Do you mean that there is some authorization policy
that is different for reregistration than for initial registration?
Thanks,
Paul
Thanks Regards
Sourav Dhar Chaudhuri
.
On Tuesday, 1 July 2014 7:53 PM, Paul
On 6/27/14 1:14 PM, NK wrote:
Dear All,
We are getting the below FROM header from one of my client. Can you please
help me to get the answer on this, whether this is valid format?
From: \241\271\324jE\032@d\200\252\bk\222\264 sip:66877610383@1.1.1.1
;tag=3612846472-761912
(I presume you are
Taisto,
You raise an interesting question.
I don't think it was one that was considered at the time.
The callerprefs/callee-caps work was under development for a long time
before it finally became RFCs. Most of the definition of the semantics
of individual capabilities was done quite early in
I agree with Brett. It is unclear exactly what you are asking.
Also, *why* are you asking? Do you want to use something peculiar? Or
are you receiving something that is causing you grief?
Note that there are inherent problems with Alert-Info - if sent from
caller to callee there can be trust
On 5/19/14 10:58 AM, Rajesh wrote:
Hi,
In the below call flow, when the UAC and UAS can start transmitting RTP
packets. I think RTP session can be started after UAS receives PRACK for
180 ringing. I would really appreciate your opinion on this. Thanks
The use of 180rel doesn't alter when RTP
- UAC (180 Ringing Require 100rel header is set) includes SDP answer
UAC - UAS (PRACK to 180 Ringing)
UAS - UAC (200 OK to PRACK)
UAS - UAC (200 OK to invite) No SDP
UAC - UAS (ACK to 200 OK for invite)
Regards
Rajesh
On Mon, May 19, 2014 at 4:17 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi
On 5/12/14 10:16 AM, Brett Tate wrote:
Hi,
I assume that Paul intended to indicate RFC6337.
Thanks Brett. Yes, 6337.
Thanks,
Paul
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On
On 5/9/14 3:37 AM, Sander Rambags wrote:
No media stream after putting call on an off hold.
1. Call connected between A and B.
2. A holds the call with a=sendonly.
3. B sends 200 ok with a=inactive
(In many cases this would be a=recvonly, but in some cases / vendors it
is
://www.iana.org/assignments/media-feature-tags/media-feature-tags.xhtml
Thanks!
-- Original --
*From: * Paul Kyzivat;pkyzi...@alum.mit.edu;
*Date: * Wed, Apr 30, 2014 00:20 AM
*To: * ankur bansalabh.an...@gmail.com; SIP
Learnerrfc3...@foxmail.com;
*Cc: * sip-implementorssip
I presume automaton is simply an error - a misspelling.
You can look in the iana registry for all the defined feature tags.
On 4/29/14 3:27 AM, SIP Learner wrote:
Hi, guys!
I am reading RFC5359 for SIP services examples, some of the message examples
contain a Contact header parameter like
On 4/29/14 7:55 AM, VARUN BHATIA wrote:
Thanks Brett, is there any specific standard which indicates that INVITE
dialog will be using same connection of REGISTER ?
RFC 5626 is the only one
Thanks,
Varun
On Tue, Apr 29, 2014 at 4:35 PM, Brett Tate br...@broadsoft.com wrote:
RFC 5626 will
...@foxmail.com wrote:
Thanks Paul!
At first I thought automaton as a typo too, but I found out that the
most recent RFC7088 also use automaton instead of automata, that's
why I asked the question.
-- Original --
From: Paul Kyzivat
is this expected to work with?
That is probably more important than what is theoretically correct.
Thanks,
Paul
Thanks.
On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote:
I read a number of the replies to this, but couldn't find an obvious place
to jump
) were designed to situations like this. But this isn't widely
deployed.
Thanks,
Paul
On Thu, Apr 17, 2014 at 6:43 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote:
On 4/17/14 12:45 AM, isshed wrote:
Thanks Paul and everyone ...
I am designing Phone1 to use only one audio and one
I read a number of the replies to this, but couldn't find an obvious
place to jump in, so I'm just replying here.
An offer multiple audio and/or video m-lines does not mean that they are
*alternatives*. Absent some explicit indication, there is no way to know
what the offerer's intent is in
You have now received answers to the question you asked.
But not to the one you should have asked: how can you do this in a way
that doesn't violate standards?
The procedure for managing new header field parameters was updated by
RFC 3968. There is an IANA registry, and you need an RFC to
Assuming P1 and P2 are truly proxies, and not B2BUAs, then (1) is
correct and (2) is not. What do you find in 3261 that makes you think it
allows (2).
Thanks,
Paul
On 3/1/14 12:10 AM, Kiran Kumar wrote:
Dear All,
I have a confusion in the following scenario.
After
with a soft phone, that has more UI options.
But this is clearly more user friendly that silently letting the
transfer fail.
Thanks,
Paul
Thanks,
Brett
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Wednesday, February 26, 2014 11:05 AM
On 2/23/14 8:32 PM, Aditya Kumar wrote:
Hi,
What is the use of UE keeping feature-tags in Contact Header of INVITE?
They indicate the features of the UAC at the time of the INVITE.
One commonly used here is isFocus.
I see some UEs keeping. feature-tags in contact of REGISTER make sense...not
On 2/21/14 6:38 AM, Brett Tate wrote:
All is well but what happens with the Session Timer response?
RFC 4028 basically allows the Session-Timer to be negotiated with every
INVITE/UPDATE request. The last 2xx response wins.
If UPDATE 2xx sent/received within an INVITE, refreshing/expiring
sunil,
This is the wrong mailing list for such a query.
You should try Sip-implementors@lists.cs.columbia.edu
Good luck,
Paul
On 2/13/14 8:36 AM, sunil kumar sinha wrote:
Hi,
SIP INVITE client transaction can retransmit INVITE seven times in case
of unreliable transport
On 1/10/14 3:40 AM, Praveena Ss wrote:
Hi Isshed,
in your example, second offer from A is correct as long as session version
id is changed in same session.
I disagree. The operable issue is in section 8 of 3264:
If an SDP is offered, which is different from the previous SDP, the
new
NK,
By default RTP goes on an even port and RTCP goes on the following odd
port. IIRC (I'm not looking this up) if the declared port is odd you are
still supposed to round it down to the previous even one for the RTP and
use the odd one for the RTCP.
But then look at RFC 3605. It defines
On 12/18/13 4:51 AM, iancu laura wrote:
Hi,
I am a newcomer to Sip and i want to clarify something from RFC 3261.
I would like to know if,for a SIP INFO method, CRLF is mandatory at the end
of each line. Should the syntax of Info be with or without CRLF at the end of
message body?
To
it be subscribing to the registration
event package.
Thanks,
Paul
Thanks,
Greg
On Wed, Dec 4, 2013 at 3:52 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi...@alum.mit.edu wrote:
On 12/4/13 4:34 PM, Greg Burrow wrote:
Hello,
After initial
On 12/4/13 4:34 PM, Greg Burrow wrote:
Hello,
After initial registration, the subscribers AOR has a single contact
binding assigned in the registrar. If the client crashes and then
recovers, it will re-register and the 200OK will contain the previous
contact binding along with the new
On 12/2/13 4:49 AM, Stephen.Paterson wrote:
Hi all,
I'm sending an INVITE with two m= lines, one audio, one video. The response I
receive only accepts the audio stream - port = 0 for the video related m=
line.
There is no global connection address and the audio description does contain
a
On Mon, Nov 25, 2013 at 6:30 AM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi...@alum.mit.edu wrote:
On 11/24/13 10:21 PM, Aditya Kumar wrote:
Hi,
Is the following valid.
A keeps B on Hold with SDP -inactive. state on both sides
offer-answer is inactive
On 11/24/13 10:21 PM, Aditya Kumar wrote:
Hi,
Is the following valid.
A keeps B on Hold with SDP -inactive. state on both sides offer-answer is
inactive.
Can A send again offer with SDP as (sendonly)--?. is this valid?
if so can you plesae point me the reference/
See RFC 6337, especially
On 11/18/13 11:31 PM, Vivek Gupta wrote:
RFC section 10.2.1 says below:
The Contact header field values of the request typically consist of SIP or
SIPS URIs that identify particular SIP endpoints (for example, “
sip:ca...@cube2214a.chicago.com”), but they MAY use any URI scheme.* A **SIP
UA
On 10/29/13 9:55 AM, Sourav Dhar Chaudhuri wrote:
Hi,
I need the expected response for the Call scenario mentioned below
1) UAC sends INVITE request with SDP
2) UAS sends 180 ringing to UAC
3) Then UAS sends 200 OK fo with SDP response INVITE .
4) Now after receiving 200 OK
responded to it.
Do you receive the ACK somewhere in here? (If you don't then the UAC is
probably broken.)
Thanks,
Paul
On Tuesday, 29 October 2013 7:53 PM, Paul Kyzivat pkyzi...@alum.mit.edu
wrote:
On 10/29/13 9:55 AM, Sourav Dhar Chaudhuri wrote:
Hi,
I need the expected
On 10/24/13 10:37 AM, Kumar, Puneet (Puneet) wrote:
Hi All,
I am seeing a case where UAC sends an in-dialog REFER but do not include
Allow: NOTIFY.
Due to this UAS is not able to send a NOTIFY with sipfrag back to UAC.
Is this valid?
What can be use case for not supporting NOTIFY?
Does
On 10/23/13 6:23 AM, Brett Tate wrote:
Also I want to know what should be the answer in this case ?
Because the offer SDP is malformed, the device can basically act how it
wants. Similarly, I assume that the behavior might vary based upon if
received within INVITE, UPDATE, PRACK, 18x, or
Not only does sip have no maximum callid length, it has no bound on the
length of most things in the message.
Of course you can usually control the length of things that you
originate, but you must not impose a limit on those you receive if you
want to be interoperable. Just get it through
Then stop calling it a *proxy*!
It is an SBC.
Thanks,
Paul
On 7/18/13 6:28 AM, ikuzar RABE wrote:
Ok thanks for your responses,
There is indeed an RTP proxy within the sip proxy... and it works as you
described above.
2013/7/17 Paul Kyzivat pkyzi...@alum.mit.edu
facing another. Removing/Adding/Changing
header values is both allowed, and maybe even expected.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: July
As others have noted, for this to happen the proxy (proxies?) needs to
modify the SDP to cause this to happen. If it does this it has violated
the rules for a proxy. Devices that do this are typically called Session
Border Controllers. It is very common. There are both advantages and
The problem with the INFO method is that you first must establish a
dialog with *something*, and you need a URI do do that. And once you
have established that dialog, all the digits you send with INFO are
going to it.
So this really only works with certain topologies, and with the calling
-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: July-16-13 11:39 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Overlap signaling in a native SIP network
The problem with the INFO method is that you first must establish a dialog
with *something
On 7/15/13 1:45 PM, Kumar, Puneet (Puneet) wrote:
Hi All,
Is it allowed to change the order of media line in SDP in case an UA sends a
reINVITE?
Consider a case where call is up with audio.
m=audio 38646 RTP/AVP 18
Now can any UA send following in the SDP:
m=image 38648
It isn't *forbidden* to do this, but it is certainly not normal
behavior. It would be somewhat deceptive, and there is no single one
right way to aggregate the capabilities of the two devices. The
likelihood that the result will be beneficial to A or B is slim.
If you want to achieve this
On 7/3/13 11:31 PM, SIP Learner wrote:
Hi, guys!
I have a question about the To header field of a SIP request, maybe there is
some misunderstanding, I hope some of you will kindly make clear for me.
Thanks in advance!
When describing how to populate the To field of a SIP request, RFC
As others have noted, session timer can be used for this, and OPTIONS is
a bad choice.
But note that session timer is primarily for the benefit of
dialog-stateful *proxies*, because they have no way to test the dialog
on their own. All session timer does is schedule a time when the dialog
On 6/11/13 9:52 AM, Johan DE CLERCQ wrote:
Scenario :
uas registers to generic proxy (next hop).
As we all know, when the uas sends a register to a proxy the register request
will have a contact header.
Upon the proxy returning 200 OK, does this 200 OK needs to have the same
contact
On 6/7/13 6:02 AM, Brett Tate wrote:
Because the message is malformed, you can basically act however you want. A
common philosophy is to be strict sending and lenient receiving. Thus unless
you have a reason to do otherwise, you might want to allow the message to
continue.
While I
On 5/28/13 10:09 AM, Kumarasami Parasuraman-QXVB36 wrote:
Hi,
Is anywhere in the RFC said Processing / generating Request, Request-URI and
To URI should be same.
There is no requirement that they be the same.
Typically they start out the same but the R-URI changes as the request
is routed
to honor the S-E in received in the
response to that invite.
I don't see anything that the N/W is doing wrong.
Thanks,
Paul
Regards
Priya Arya
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Tuesday, May 21, 2013 12:34 AM
To: sip
On 5/20/13 6:53 AM, ANAND KUMAR wrote:
Hi,
I have a query for method available in Request URI.
According to rfc 3261 section 19.1.5
If the URI contains a method parameter, its value MUST be used as the method
of the request.
Now suppose the UAC receives 302 Moved Temporary with Contact
On 5/20/13 2:12 PM, Priya Arya wrote:
Hi All,
I have certain queries about the session timer behaviour in the SIP Stack.
The scenario is as follows :
SIP Stack
N/w
At T0s
INVITE
On 5/8/13 10:23 AM, Uttam Sarkar (usarkar) wrote:
It's a deregister request. So you need to remove all the bindings for that
AoR.
As Brett said, this comment is *wrong*!
The expires is applied to the specific contacts supplied in the
REGISTER, in this case none.
If you want to deregister
Terry,
On 5/7/13 10:29 AM, Terry Song wrote:
Hello Everybody,
I have a question about the RFC4028 session timer of invite usage. The
section 7.1 says:
7.1. Generating an Initial Session Refresh Request
A UAC that supports the session timer extension defined here MUST
include a
On 5/6/13 9:37 AM, SIP Learner wrote:
Thank you very much for your valuable information Paul!
I did some homework after receiving your kind reply. But I still have
some new question concerning your answer, I hope you (or some other
fellow guys on the mail list) will again take some time to
Zhang,
On 5/4/13 6:31 AM, SIP Learner wrote:
Hi, everyone!
I am a newcomer to SIP and I have a problem with Section 8.1.1.2 of RFC3261.
Following is a short qoute from Section 8.1.1.2 of RFC 3261 (I enclosed the
key sentence within asterisks to make them stand out):
A UAC may learn
On 4/30/13 8:19 AM, Sithara Santharam wrote:
Hi,
Can someone point me to references which describe how a SIP auto-attendant
(IVR) must behave in various scenarios?
For example when a user calls the auto-attendant and asks to transfer to
another extension. This extension doesn't asnwer and
On Sat, Apr 27, 2013 at 7:16 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi...@alum.mit.edu wrote:
Can you provide the complete INVITE and CANCEL messages?
Normally, when a CANCEL is sent there is as yet no dialog.
The rules for forming the CANCEL message mean
201 - 300 of 926 matches
Mail list logo
