RFC 3261 suggests "480 Temporarily Unavailable" is ok for "do not disturb".
For me declining manually is no different to declining automatically
Regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.
net]
Sent: 19 April 2011 14:19
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Stateful proxy and CANCEL for a non
matchingtransaction => 481?
2011/4/19 Attila Sipos :
> It is saying you MUST forward it.
> You forward it (without creating state)
It is saying you MUST forward it.
You forward it (without creating state) to the endpoint to which you would've
forwarded a similar INVITE.
I think this is a best-effort and I don't think is 100%-guaranteed to get to
where it needs to go.
Like what about sequential forking scenarios?
I'm not su
Hi Manoj,
I did ask about phone-context a while ago:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-March/0188
35.html
RFC 3966 might help too:
http://www.rfc-editor.org/rfc/rfc3966.txt
Regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia
If you delve into the grammar you can see that
characters which are not in character lists are "escaped".
For example:
user = 1*( unreserved / escaped / user-unreserved )
All escaped characters start with %.
So for the '%' character, you have to have %25
or '^' is %5E
regards
Atti
RFC 6086 says:
7.2. Info-Package Header Field
This document adds "Info-Package" to the definition of the element
"message-header" in the SIP message grammar [RFC3261]. Section 4
describes the Info-Package header field usage.
For the purposes of matching Info Package types indicate
Record-Route is used to learn the route set.
If proxies want to be in the the route set, they
add themselves in using Record-Route. By being in
the route set, they will get traversed for all
requests between two SIP endpoints. One more point,
the route sets at the originating and terminating
end
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Kevin P. Fleming
Sent: 24 March 2011 11:12
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] about md5()
On 03/24/20
s-boun...@lists.cs.columbia.edu] On Behalf Of
Attila Sipos
Sent: 24 March 2011 05:37
To: Kevin P. Fleming; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] about md5()
The mechanism and algorithm for SIP authorization is taken from
http://www.ietf.org/rfc/rfc2617.txt
There is an alg
The mechanism and algorithm for SIP authorization is taken from
http://www.ietf.org/rfc/rfc2617.txt
There is an algorithm parameter which is normally set to "md5".
I would've thought this could be changed to something else.
Only problem then might be interop!
If the server can't do "sha1", is t
there is info here...
http://lmgtfy.com/?q=sdp+tias
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of titan mtp
Sent: Wed 23/03/2011 05:01
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Basic questions on SDP
Hi All
I am rea
vsf, vst and did are other opaque parameters (I think).
Again they are probably legal grammar.
You should check the grammar to see if '-' and '.'
characters are allowed. (I think they are)
Regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:si
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Ftag Parameter in Record-Route
Dear All,
Could you please help me on this to understand this.
Thanks,
Nitin
On Tue, Mar 22, 2011 at 9:46 AM, Attila Sipos
wrote:
> Hi,
>
> I'm saying that the ftag parameter is a l
valid pvalue
ftag=4F6C3030343338350007D3E5;
Regards
Attila
From: Nitin Kapoor [mailto:nitinkapo...@gmail.com]
Sent: 22 March 2011 13:36
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Ftag Parameter in Record-Rout
Record-Route headers often have opaque parameters which are
not in any draft or RFC. Such parameters have no meaning except
to the entity which added them.
For Record-Route all you have to do is reflect the route back.
When you use the learnt route in a Route header you have to
quote the full le
>>I think that values above 100 are not standard so maybe they require "a="
>>line (so you would be right).
The dynamic payload types are between 96 and 127 inclusive.
These dynamic payloads would require an "a=" line.
Regards
Attila
-Original Message-
From: sip-implementors-boun..
18x or 200 in the INVITE transaction should not contain any SDP.
regards
Attila
-Original Message-
From: ashok kumar [mailto:ash@gmail.com]
Sent: Fri 11/03/2011 09:57
To: Jaiswal, Sanjiv (NSN - IN/Bangalore)
Cc: Attila Sipos; sip-implementors@lists.cs.columbia.edu; Nitin Kapoor
l, Sanjiv (NSN - IN/Bangalore) [mailto:sanjiv.jais...@nsn.com]
Sent: Fri 11/03/2011 10:07
To: Attila Sipos; ext ashok kumar
Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor
Subject: RE: [Sip-implementors] Different SDP Session Version in 183 & 200 OK
Hi Attila,
Take for example
ashok kumar; Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor
Subject: RE: [Sip-implementors] Different SDP Session Version in 183 & 200 OK
Hi Ashok,
The SDP from 183 is considered as Answer of initial offer.
Different SDP in 200 OK is considered as new offer and then i
is accepted the UPDATE offer/answer exchange gets lost.
Fortunately, there is not a lot of usage of "early" UPDATEs
and so the "broken" UAs will still work if you accept the 200 OK's SDP.
Regards
Attila
-Original Message-
From: ashok kumar [mailto:ash....@gmail.com]
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Attila Sipos
Sent: 10 March 2011 09:19
To: Jyoti Singhal
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Significance of
all control techniques.
From: Jyoti Singhal [mailto:jyoti.na...@gmail.com]
Sent: 10 March 2011 08:58
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Significance of different PAID header
inRe-INVITE
But once a dialog is established betwe
I my experience it means that the identity of the connected party has changed.
say you have a SIP gateway to some non-SIP network.
If a transfer occurs inside the network then the SIP
endpoint could become connected to a different user.
The SIP UA will update the P-Preferred-Identity
from RFC 3
Strictly, for an error like that, there should be a "404 Bad Request"
response
but you might decide it is better to treat it as if it is missing:
If the Content-Disposition header field is missing, bodies of
Content-Type application/sdp imply the disposition "session", while
other content
>> As you say, URI host name is case-insensitive.
sorry, URI host name is NOT case-insensitive.
regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Attila Sipos
Sent: 09 March 2
I think it's a bug.
As you say, URI host name is case-insensitive.
(most of SIP is case-insensitive - there are exceptions like
display-name or RFC4916's Identity header)
Regards
Attila
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implemen
There is a draft which tries to clarify what is legal.
http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13
OfferAnswer RFCIni Est Early
---
1. INVITE Req. 2x
> 183 as well as in 200 OK also. As far as i know if we are getting SDP
> in 183 session progress then my UAC can ignore the SDP in 200 OK.
I agree 100%.
Unless the 200 OK was on a different "fork" (i.e. different To tag)
then the SDP of the 200 OK should be ignored.
The SDP should not be chang
>>2. Just for double confirmation is it normal that the port "from
which" I send my
>>RTP is irrelevant
It is not normal.
It is not totally irrelevant.
For NAT traversal "symmetric RTP" is important.
See section 4 of tfc 4961: http://tools.ietf.org/rfc/rfc4961.txt
Also some equipment may require
___
From: Siga [mailto:fruchta...@googlemail.com]
Sent: 07 March 2011 17:59
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Ports for sending and receiving RTP
packets!
Hi Attila,
thanks for your reply. I am sure that I know this is how it shou
>> is this normal to send RTP packets from the local port = *5060(SIP
PORT)*
>> with remote port = *18564 *and receive RTP packets from SIP Server on
local
>> port = *22456 * with remote port = *18564.
You are confusing 2 separate things:
1. there is a SIP signalling port 5060 - this is used only
You can use either according to RFC 5630.
However, using "sip" with TLS does not guarantee that all hops will use
TLS so it is not as secure as you might think. "sip" with TLS is only
guaranteed to be secure to the nearest hop.
On the other hand, "sips" means that all hops should use TLS so this
B must send RFC2833 using payload 96
and A must send RFC2833 using payload 101
regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
varun
Sent: 29 November 2010 10:31
To: sip-implem
I think it is clear once you carefully read the descriptions in RFC3261.
415 relates to the format of the content in the SIP message body.
So 415 is most commonly used where there is a Content-Type that the
receiver cannot understand.
I think it is mandatory that SIP implementations understand SDP
it's more than possible.
It's mandatory in RFC 3621.
(but you wouldn't believe it if you just looked at the huge number of
applications that are UDP-only!)
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
>>Usually it is simpler to implement the following strategy:
>>
>> - If the message is below 64K, send the message using UDP.
>> - If the UDP transaction times out, try TCP transport.
Simple, yes.
But bad also.
Why do people want to use UDP for large messages?
It's a great way to block things u
By adding privately-encoded information into record-route (or via
headers)
you can use it for whatever you want. (so the messages store state
information instead of storing it in the stateless proxy)
Regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.ed
ere unsure about this)
Regards
Attila
-Original Message-
From: Ayyanar P K [mailto:ayyanar...@aricent.com]
Sent: 11 October 2010 13:26
To: Attila Sipos; Vivek Batra; $...@r\/|>r!`/@; Vijay S Nair
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] UAS behavior
Be careful because the behaviour in the described scenario is only
allowed if all the SDPs are the same.
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specific
: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Attila Sipos
Sent: 14 June 2010 08:42
To: Roman Shpount; Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Implementing RFC 5626 CRLF Keep Alive
>
> If a
>
> If a pong is not received within 10 seconds after sending a ping (or
immediately after processing any incoming message being received when
that 10 seconds expires), then the client MUST treat the flow as failed.
>
>
> What does "immediately after processing any incoming message" is
supposed to
>>I think the double quotes are allowed in the Reason Phrase.
>>
>>Reason-Phrase = *(reserved / unreserved / escaped
>> / UTF8-NONASCII / UTF8-CONT / SP / HTAB)
I don't think they are allowed.
They are only allowed if escaped - so they're not allowed "naked".
reserved
that similar (yet totally different) technology is used
for SIP mobile phones?
Regards
Attila
-Original Message-
From: Avasarala Ranjit-A20990 [mailto:ran...@motorola.com]
Sent: 30 March 2010 09:50
To: Attila Sipos; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] w
If you have a SIP call and you have two fully independent and unreliable
networks, what technology can be used
to automatically/seamlessly switch a live call from network to another
(as one network goes down)?
.
___
Sip-implementors mailing list
S
t;
> --- En date de : Jeu 18.3.10, Attila Sipos a
> écrit :
>
> De: Attila Sipos
> Objet: RE: Re : [Sip-implementors] does sips imply TLS (and TLS alone)?
> À: "Bossiel thioriguel" ,
> sip-implementors@lists.cs.columbia.edu
> Date: Jeudi 18 mars 2010, 11h54
>
User-Agent should (by default) use TLS to send requests back.
Regards
Attila
From: Bossiel thioriguel [mailto:boss...@yahoo.fr]
Sent: 18 March 2010 12:27
To: sip-implementors@lists.cs.columbia.edu; Attila Sipos
Subject: RE: Re : [Sip-implementors] does
transport=TCP" and
sending sips over TCP (though allowed) is totally pointless isn't it?
From: Bossiel thioriguel [mailto:boss...@yahoo.fr]
Sent: 18 March 2010 10:34
To: sip-implementors@lists.cs.columbia.edu; Attila Sipos
Subject: Re : [Sip-implement
If a SIP Contact header has a sips URI, does that mean that one must
send requests using TLS?
Or is there some other secure protocol that one could use?
(my problem: our equipment sends a sips contact and some other vendor
said they'd like to see ";transport=tls" in the Contact
but my belief
no, B has not told A that it can do G726.
So client A must not expect G726 after the response.
your offer and answer should result in:
AB
By the way, If B had responded
m= PCMA, G729
then it would be allowed to have:
APCMA>B
A
In response to a question "[Sip-implementors] Global and local - SIP
URI",
it was written:
>>If the SIP URI has a param ;user=phone then the userinfo part is
supposed to
>>be a telephone number, sharing syntax with the TEL URI.
>>
>>So you could consider the following SIP URI as "global" (in term
There are more SIP response codes than relevant ISDN mappings
so translations can result in loss of original response code.
For ISDN-->SIP--->ISDN, this problem can be reduced by using
the SIP Reason header ( http://www.rfc-editor.org/rfc/rfc3326.txt )
where a Q.850 cause code can be specified.
I don't know why but they removed the "hookflash" event
when they went to RFC 4733. (but event 16 isn't taken anyway)
Regarding your SDP:
The server might not like the 0.0.0.0 in the o= line?
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-impl
Agree with Iñaki that logic alone should be enough but
to satisfy the infidels(!), I found this in RFC 3261:
o The initial offer MUST be in either an INVITE or, if not there,
in the first reliable non-failure message from the UAS back to
the UAC. In this specification, th
V | <- SDP should not be included in the
|<|final response once offer/answer has
| F13ACK |been completed.
|>|
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun.
there is no "exchange" as such.
Just that both proxy and UA have been independently configured with the same
password.
Regarding a sort of exchange: There is a nonce sent back by the 407 which is
then used in a hashing function
with the password. Since both ends know the password and the nonc
>>Anyhow, even when using 100rel I "think" (not 100% sure) that the
>>SDP must be included in the 200 OK even if it's just a copy of the
>>SDP in a previous provisional response. Hope somebody else could
>>confirm this.
Strictly, once the 180 has been PRACKed, the 200 OK must not have SDP.
IIRC, t
Your scenario is not valid unless PRACK is used.
I hope this logic convinces you without an RFC3261 reference:
1. It's not valid because the 180 could've been lost.
2. Then when the 200 OK is received there will be no media.
-Original Message-
From: sip-implementors-boun...@lists.cs.c
should inspect to
order the mails by threads).
Regards.
El Martes, 24 de Noviembre de 2009, Attila Sipos escribió:
> >>UA needs to know and publish its public IP address/port.
>
> this is true in some cases. If you are a standalone UA (not using a
> SIP server) and want
ions
in SIP)
for UDP SIP signalling.
Regards
Attila
-Original Message-
From: Vivek Batra [mailto:vivek.ba...@matrixtelesol.com]
Sent: 24 November 2009 11:49
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu;
sip-implementors-requ...@lists.cs.columbia.edu
Subject: RE: [
ric NAT.
point 1 I'm not so sure about but points 2 and 3 make rport useful
Regards
Attila
From: KEERTHI KUMAR [mailto:thov...@yahoo.co.in]
Sent: 24 November 2009 11:00
To: sip-implementors@lists.cs.columbia.edu; Attila Sipos
Cc: thov...@yahoo.
STUN doesn't work for all NAT types, I believe rport does.
rport is a very simple mechanism without very low overhead for achieving
simple NAT traversal without requiring a separate protocol such as STUN
which requires a STUN client and STUN server.
rport's use cases are not unique but for UDP SI
I agree, it's nonsense.
what is the purpose of putting port 0 in request URI?
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: 19 November 2009 08:43
To: sip-impleme
interesting. "Spotter's badge" for you!
I suspect that SIP changed it because it is best to have
to most important headers at the top - less time to parse down?
Since the top via is the most important (most relevant)
I guess reversing the via order is a SIP optimisation!!
-Original Mes
e the RFC2833 play for the duration
of the tone.
Regards
Attila
-Original Message-
From: Mike [mailto:m...@fonolo.com]
Sent: 13 October 2009 02:10
To: Attila Sipos; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] RFC 2833/4733
Thanks for your feedback Atti
This can be a tricky subject - there are many different behaviours.
I think your approach is ok but you should make the rfc2833 last for
the duration of your key-press.
>>1) The duration increments seem to be in-consistent from
>>packet-to-packet- how important, if at all, is this? Also, ho
, always implement "SHOULD" requirements.
So if A says 97, B should also say 97 but if it doesn't, A must use the
PT specified by B.
From: Socaciu, Vlad [mailto:vlad.soca...@unisys.com]
Sent: 14 September 2009 01:39
To: Attila Sipos; Stefa
Note also this (also from RFC3264):
In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.
This means, as an example, that if 97 was used for telephone-events
i
Yeh, the mule draft is the de-facto standard I think.
I believe the called party should send the re-invite because
it is the called fax machine which sends a tone back to say
"I'm ready to switch to fax". CED tone, I think.
Regards
Attila
-Original Message-
From: sip-impl
This is now a SIP overload list:
https://www.ietf.org/mailman/listinfo/sip-overload
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Tharindu Thundeniya
Sent: 24 June 2009 16:05
To: sip-impleme
sounds like you're in dire straits.
>>I tried to build the things but it failed.
I don't know what you mean by "build".
The first step is to make a successful registration with the server.
But in general I'd recommend you e-mail the knopflerfish group
http://www.knopflerfish.org/mailman/listin
>>** - At this moment UAS (which is actually a B2BUA) establishes a session
>>with another
>>proxy where it uses 100Rel and now it is trying to "back-enable" 100Rel in
>>our call leg.
that is not possible.
I don't even think 100rel makes sense for an INFO request.
Also I think the lifetime of 1
what you are using is correct.
But not everyone supports it!!
( in g729, you can do: a=fmtp:18 annexb=no )
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Brad Johnson
Sent: 16 June 2009
quot;Path" feature disabled.
-Original Message-
From: Brad Johnson [mailto:bjohn...@ecessa.com]
Sent: Mon 6/15/2009 4:53 PM
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Same SIP URI registered from multiple phones
FYI: one server that
>>server sends back an OK response, but the Contact contains no additional
>>attributes, and so it seems it has ignored the "Path" altogether
Just one thing, are you putting in "Require: path"?
That would help.
I guess you probably are because I have seen at least 2 well-known
SIP-server type pro
>>182 doesn't mean "call-waiting", it can mean "call-waiting", "queued"...
It's the same thing isn't it?
If you've got a "call-waiting", then your call is queued to be answered.
And you're queuing, you're a call that is waiting to be answered.
For me, call-waiting is a type of queue (a queue of
One more thing.
I have seen UAs refresh the session using an UPDATE without any SDP.
Doing it this way doesn't change any of the codecs.
RFC 4028 says:
It is RECOMMENDED that the UPDATE request not contain an
offer [4], but a re-INVITE SHOULD contain one, even if the details of
the sessio
yes, the call flow is fine.
But I can understand why you are confused.
The important part is this:
For this specification, that is
only the final 2xx response to that INVITE.
"For this specification" is important.
It allows for extensions which might permit other behaviour.
In
according to RFC 3515
.4.7 Using the Subscription-State Header Field with Event Refer
Each NOTIFY must contain a Subscription-State header field as defined
in [2]. The final NOTIFY sent in response to a REFER MUST indicate
the subscription has been "terminated" with a reason of "noresou
It seems unusual but if it did happen, you'd have not much choice
but to abandon the session.
A more realistic example...
uac send INVITE
uas send 100 Trying
uas send 180 Ringing
times out after ringing for (for example) 60 seconds.
uas send 480 Temporarily Unavailable.
Regards,
Att
AFAIK, 100 Trying doesn't require a to-tag when responding to a
session-establishing INVITE.
This is because the dialog hasn't been established yet.
Is a to-tag required in the 100 Trying response to a re-INVITE?
It seems to me that it probably should be (since the dialog is now
established) bu
would recommend you ask this question to
a...@ietf.org
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Erez Morabia
Sent: 06 May 2009 04:41
To: sip-implementors@lists.cs.columbia.edu
Subject: [Si
>>and any UAS insisting on an increase of one and one only would reject a
>>perfectly legitimate, in order, request.
No, that's not right. The UAS doesn't insist on an increment of one.
It only insists that CSeq is increasing.
>>If it is allowed for multiple transactions to exist, I must let
[much better to split up the question]
>>but I receive it on UDP, should I strip it?
I'd leave it, I don't think it matters much, you would
strip the top Route anyway (if the top route is you).
(unless you had different applications running on UDP and TCP,
I don't think it's important)
>>W
415 is often confused with 488.
"415 Unsupported Media Type" is what you would use if if didn't understand
the SIP message body content.
488 (which is similar to 606) would be a more suitable response:
21.4.26 488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable),
>>Is it must to send 'timer' tag extension in
>>Supported: header if Session-Expire:
>>60;refresher=uac/uas header is present in a request?
it is a must to send 'timer' tag in a request if you want it to work
>>What should be the behaviour if UAS receives a message
>>including the header "Sess
port is probably going to be more successful.
(just make sure your fingers are crossed)
Attila
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Iñaki Baz
Castillo
Sent: Mon 20/04/2009 19:53
To: sip-implementors@lists.cs.columbia.edu
Subject
t: 20 April 2009 14:24
Cc: sip-implementors
Subject: Re: [Sip-implementors] rport parameter question
2009/4/20 Attila Sipos :
> If the rport is important to the UAC, it should signify this by
> including rport in its via.
> Why doesn't his UAC just add an rport in its request?
Because rp
>> The question I have is what is the UAS supposed to do when the
inbound
>>request does NOT have an rport parameter? Is it legal ( or illegal )
>>to attach an rport parameter in the response when the request does
not have it?
It's technically illegal.
If a UAC receives the rport when it didn't
o
me.
Thanks and Regards,
Attila
From: Singh, Indresh (NSN - US/Boca Raton) [mailto:indresh.si...@nsn.com]
Sent: Fri 17/04/2009 21:33
To: Attila Sipos; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] weird multiple dialog usage
possibil
Questions on some strange multiple dialog possibilities...
Scenario 1
--
INVITE/OK/ACK> - INVITE creates dialog1
SUBSCRIBE/OK-> - SUBSCRIBE usage added to dialog1
BYE/OK---> - INVITE usage terminated with BYE
So this leaves a S
[mailto:shamik.s...@wipro.com]
Sent: 16 April 2009 15:58
To: Attila Sipos
Cc: pkyzi...@cisco.com; br...@broadsoft.com;
sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
But section 12 of RFC3261 says that if a 481 response is received within
a dialogue then the
to get destroyed too. A new subscription could
be created after (if required).
-Original Message-
From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com]
Sent: 16 April 2009 15:34
To: pkyzi...@cisco.com
Cc: br...@broadsoft.com; Attila Sipos;
sip-implementors@lists.cs.columbia.edu
Subje
eaning of "last usage".
"Last usage" means the "last remaining usage", not "last created".
Also, BYE is ONLY related to INVITE usage.
BYE is not defined for any other usage.
Regards,
Attila
-Original Message-
From: shamik.s...@wipro.com [mailto:sha
the 481 should only destroy the usage.
-Original Message-
From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com]
Sent: 16 April 2009 14:12
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
But in RFC 5057 page 9
m: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com]
Sent: 16 April 2009 14:02
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
I understand that a 481 response will terminate the SUBSCRIPTION
usage,at the subscriber`s end but at the
Sent: 16 April 2009 13:33
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
Yes I absolutely agree with you,I agree that allowing only one method to
both begin and end subscriptions is a good thought.
But still for the purpose of
ro.com [mailto:shamik.s...@wipro.com]
Sent: 16 April 2009 12:14
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
Yes that will be fine for de-bugging purposes but the UAC will never
come to know what cuased the problem and try to ove
s for your responses.
Regards,
Attila
-Original Message-
From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com]
Sent: 16 April 2009 11:15
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
Now we can think of two scena
o:shamik.s...@wipro.com]
Sent: 16 April 2009 08:37
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] BYE after SUBSCRIBE?
A problem with 481 can be that the subscriber receiving 481 will
consider the dialog as terminated,but the notifier will retain the
As we know, when a new SUBSCRIBE occurs, it creates a dialog.
But what should one do when a BYE is received on a SUBSCRIBE dialog?
I don't think "405 Method Not Allowed" is right but maybe "481"?
I can't believe that BYE should clear the dialog because, IMO, BYE is
only
valid for INVITE-creat
1 - 100 of 262 matches
Mail list logo
