l
> -----
>
> Thanks,
> Prashanth M E
>
> Paul Kyzivat wrote:
>> The form of the user part is really the responsibility of the owner of
>> the domain. user=phone is really only meaningful if the domain owner
>> allows/supports that. In absence of us
ietf for help on this. (E.g. Christer Holmberg, Gonzalo Camarillo)
Thanks,
Paul
> Nancy
>
> -----Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: March-15-10 10:42 AM
> To: Nancy Greene
> Cc: SIP-implementors mailing list
> Subjec
l
> Nancy
>
> -Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: March-15-10 9:08 AM
> To: Nancy Greene
> Cc: sipc...@ietf.org
> Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI?
>
> Nancy,
>
> Ques
This is addressed by RFC 5057.
The transaction times out and fails, but neither the dialog nor the
invite dialog usage are affected.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> Hi, an easy scenario:
>
> - A calls C through a B2BUA and the call is established with direct
> audio bet
Specifically regarding session timer:
every UPDATE or reINVITE renegotiates the use/non-use of the timer and
the timer value. So you may start with it off, and later turn it on, or
start with it on and later turn it off. If you're not careful, you may
start with it on and inadvertently turn it
the way 3264 is worded, any of the codecs in the offer may be used to
send toward the offerer, and any of the codecs in the answer may be used
to send toward the answerer.
However in practice I think you will find that many implementations only
support sending and receiving using codecs in the
Attila Sipos wrote:
> So this leads me to another question:
>
> What is the practical difference between:
> sip:+12345...@domain.org;user=phone
> and
> sip:+12345...@anotherdomain.org;user=phone
and
tel:+12345678
> ?
>
> Is it that in the first case, the request gets sent t
The form of the user part is really the responsibility of the owner of
the domain. user=phone is really only meaningful if the domain owner
allows/supports that. In absence of user=phone, the domain may *choose*
to treat the user part according to tel uri syntax, or not.
*if* user=phone is pres
lik Shah (maushah)
> *Sent:* Tuesday, February 23, 2010 9:28 AM
> *To:* Vinay Pande (vipande); artg-sip-bliss(mailer list); Toleti Danayya
> Naidu (naidud); Paul Kyzivat (pkyzivat)
> *Subject:* RE: RFC 2833 / RFC 4733 - question on duration "0"
>
> Hi Vinay
>
>
>
If you aren't interested in the NOTIFY, you can use the norefersub
option to bypass the subscription altogether.
Alternatively you could use the information about a failure to alert the
transfering user in some way - display a message, blink, etc. From a
practical perspective, I think a user th
> Anders
>
> On 2/22/2010 1:40 PM, Paul Kyzivat wrote:
>> At end...
>>
>> Aaron Clauson wrote:
>>>> -Original Message-
>>>> From: Dale Worley [mailto:dwor...@avaya.com]
>>>> Sent: Monday, 22 February 2010 4:42 PM
>>>&g
At end...
Aaron Clauson wrote:
>> -Original Message-
>> From: Dale Worley [mailto:dwor...@avaya.com]
>> Sent: Monday, 22 February 2010 4:42 PM
>> On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
>>
>> You should be able to do this in a standard way.
>>
>> First, let us assume that
Roman Shpount wrote:
> From/To header should be preserved completely with all of its parameters
> to be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues
> Response says that "The response MUST copy the To, From, Call-ID, CSeq
> and Via fields from the request." This implies that c
Brett Tate wrote:
>> Question is: Should the To in that (re)INVITE
>> contain ';foo=bar' ???
>>
>> AFAIK the contents of that To header are to be generated
>> from dialog state information. The URI and the tag are
>> part of that state, but other header parameters from the
>> original INVITE
Iñaki Baz Castillo wrote:
> El Miércoles, 17 de Febrero de 2010, Paul Kyzivat escribió:
>> AFAIK the contents of that To header are to be generated from dialog
>> state information. The URI and the tag are part of that state, but other
>> header parameters from the origina
I got queried about this when an interop problem popped up.
I know what I think the right answer is, but want to check what others
think.
Here is the case:
Alice calls Bob:
INVITE ...
From: ;tag=;foo=bar
this succeeds and a dialog is established.
Then, within that dialog, Bob sends a
Once the first INVITE has failed, and early dialog it might have had is
gone. The retried INVITE is working toward establishing a new dialog. So
the CSeq values are for that dialog. I think that means the CSeq
numbering should be permitted to restart.
OTOH, if there are any messages still in tr
To be anonymous with a tel URI, just lie and use somebody else's number.
Or, you could do something like:
tel:0;phone-context=anonymous.invalid
But AFAIK there is no *standard* way of doing it.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> El Miércoles, 13 de Enero de 20
I'm going to get a bit nit-picky here. The text from 3261 says:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like telephon
Iñaki Baz Castillo wrote:
> El Miércoles, 13 de Enero de 2010, ROHIT CHAUDHARY escribió:
>> Hi experts,
>>
>> A sip-uri with user part as "anonymous" is allowed. But if the user
>> parameter is phone, ie, the user part is to be treated as
>> telephone-subscriber of tel-url (RFC 3966), then shou
Rajanikanth wrote:
> But in RFC5627(GRUU) it's mentioned that Call-ID can change in register
> refresh requests,if UA wants to invalidate temp-gruu.
> Can we change call-ID in the register refresh requests?
Sure you can change the callid from one REGISTER request to another. In
that case it is
Pandurangan R S wrote:
>> In such a case UAC and NOTIFIER would destroy then SUBSCRIBE
>> dialog quietly.
>
> NOTIFIER will destroy the dialog as per RFC3265.
> But how/why did the UAC destroy subscribe dialog? I think it has to
> wait for the NOTIFY.
>
>> Now my questions are -
>> 1. Does the
If your proxy refrains from adding itself to the Record-Route header, it
will not remain in the chain. (You must take overt action to stay in.)
But note this is for *proxies*, not B2BUAs.
Paul
Mihaly Zachar wrote:
> Hi Gents,
>
>
> How is it possible to drop off a SIP chain after the
IMO it would be inappropriate to send a 491 in this case, because it is
not glare, and it is perfectly ok to terminate the dialog. Given that it
has sent the BYE, I *think* it would be ok for S to send a 481 to the
reinvite. (But I haven't scrutinized the state machines regarding this.)
If not
Remember that there are two views of whether a dialog exists: one by the
UAC and one by the UAS. The goal is for them to agree, but there are
points in time when they don't agree.
So when the UAS sends a response < 300 with to-tag, *it* thinks there is
a dialog. This is true regardless of wheth
To be charitable, we should assume that the UAC is trying to do the
right thing. So presumably it *sent* the PRACK (which was then lost or
delayed), and then sent the UPDATE without awaiting the reply to the prack.
The UAS can infer from the UPDATE with offer that the 183 was received,
and that
Iñaki Baz Castillo wrote:
> El Martes, 1 de Diciembre de 2009, Paul Kyzivat escribió:
>
>>> So, is there any SIP core in which such URI's exist for its users?
>>> Of course "they COULD exist", however I want to know if they *really*
>>> ex
Iñaki Baz Castillo wrote:
> Hi, if there any *real* case in any SIP core (i.e: IMS) in which a user could
> have a URI with parameters?
>
> Usually it doesn't occur as any network/provider users have an identifier
> like:
> - sip:al...@domain.org
> - tel:+12345678
>
> However I wonder if
sunil.bha...@wipro.com wrote:
> Hi,
>
> Say, UAS doesn't have any endpoint configured and will not be able to handle
> calls. In this case, should the UAS send a 4xx response, say 408 timeout,
> when it receives OPTIONS request, or is it better to ignore the incoming
> OPTIONS request and not
Aniruddha Vaidya wrote:
> Hi,
>
> I have a doubt on this. Should this behavior be of stateful proxy or can
> stateless proxy also do this? In my understanding, a stateless proxy should
> not do anything on its own and it should actually pass it to UAC. Is this
> understanding correct or stateles
Mayank Gupta wrote:
> Hi Ritul
>
> Is there any significance of this additional message for INVITE?
>
> ACK for initial INVITE request makes sense as it may be useful for
> offer-answer when initial INVITE is without SDP and offer is received from
> called party in 200 OK. In that case ACK wil
Brez Borland wrote:
> Hi all,
>
> Below I assume using tcp transport for registrations.
>
> As I understand, while using a reliable transport for dialogs the
> connection between UAC and the next hop is active until the dialog is
> terminated by one party sending BYE and another party respondin
Victor Pascual Avila wrote:
> On Tue, Oct 13, 2009 at 11:12 AM, Jin-Soo Eo wrote:
>> Hello,
>>
>> I would like to know how to reuse Server Connection other than
>> mentioned in draft-ietf-sip-connect-reuse-03.
>> I think most SIP entities do not support draft-ietf-sip-connect-reuse-03 as a
>> wa
David Benoit wrote:
> On Fri, Oct 02, 2009 at 04:22:55PM -0400, Dale Worley wrote:
>> On Thu, 2009-10-01 at 10:37 +0200, DE CLERCQ Johan wrote:
>>> As we all know, in ISDN you can detect when you go to a voicemailbox of
>>> a cellular line by looking for the PROGRES message as defined in Q.931.
>
To elaborate:
There is no standard for DTMF over INFO.
The usages that exist in the wild are *proprietary* though you may find
some commonality. If you need to use this to interoperate with
something, do whatever your peer expects.
Thanks,
Paul
Avasarala Ranjit-A20990 wrote:
>
Alex Balashov wrote:
> I cannot easily tell from 3261 whether references to URIs other than the
> Request URI must be encased in "<" and ">" or not, probably because I do
> not know how to read BNF.
If you are involved in SIP, or almost any IETF protocol, then I strongly
suggest that you *lea
krishna chaitanya wrote:
> Hi All,
>
> I have question regarding implicit de-registration.
This isn't the ideal place to ask this question.
Implicit registration is not part of any ietf standard,
its a creation of IMS.
> 2 IMPUs belonging to same IRS( Implicit registration set) are registered
Yong Xin wrote:
> Hi,
>
> The RFC3261 is clear that UA can not send a re-INVITE when another
> INVITE is pending. However, for non-INVITE request (e.g.: INFO), I was
> not able to find any restriction like this. So I assume this is allowed.
>
> However, sending another INFO before the previo
aul
> Regards
> Ranjit
>
> -Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: Tuesday, August 25, 2009 12:07 AM
> To: Avasarala Ranjit-A20990
> Cc: sunil.bha...@wipro.com; s...@ietf.org;
> sip-implementors@lists.cs.columbia.edu;
Avasarala Ranjit-A20990 wrote:
> no it should not. For a Hold request, you do not send any media
> capabilities. U only change the existing media description lines to
> indicate HOLD.
I beg to differ.
Technically there is no HOLD request.
All there is is an offer that offers to change a media a
would
be a natural thing to do. In that case the other end will have the
opportunity to refuse at codec.
> I think this is a problem for RFC3264.
> What do you think about this reINVITE ?
I'm not seeing what the problem is.
Thanks,
Paul
> Regards,
> Shinji
&g
on."
> Regards
> Satya T
>
> -Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: Tuesday, August 18, 2009 7:53 PM
> To: T Satyanarayana-A12694
> Cc: Dale Worley; sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-impl
soma bhargava wrote:
> Hi All,
>
> As per RFC 3261
> sec 8.2.2.3 Require:
> An ACK request for a 2xx response MUST contain only those Require
> and Proxy-Require values that were present in the initial request.
I think that is less than ideal wording.
It would have been better worded as:
"An A
oth parties adhere
to it.
Thanks,
Paul
T Satyanarayana-A12694 wrote:
>
>
> -Original Message-
> From: Dale Worley [mailto:dwor...@nortel.com]
> Sent: Tuesday, August 18, 2009 1:37 AM
> To: T Satyanarayana-A12694
> Cc: Paul Kyzivat; sip-implemen
Dale Worley wrote:
> On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
>> Additional round trips should be made optional (only for implementations
>> having concurrent codecs limitation).
>>
>> Additionally, why can't the spec be modified (or place in a BCP):
>> 1. to allow only a
Bhaskar Dutta wrote:
>> I had a doubt on History-info header present in Sip 18x Responses.
>>
>> Are the History-info headers UAC received in 18x response useful to an
>> application or user ?
>>
>> If yes can you please quote an example where its useful to an
>> application/user .
This is entir
hear what is implemented in practice - perhaps
stats from SipIt.
Thanks,
Paul
> Thanks
> Regards,
> -Rockson
> -Original Message-
> From: Paul Kyzivat (pkyzivat)
> Sent: Saturday, August 15, 2009 7:54 AM
> To: Dale Worley
> Cc: Rockson Li (zhengyli
comment at end.
Dale Worley wrote:
> On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote:
>> I think answerer can add additional codec G729 here per sec 6.1 of
>> rfc3264
>>
>>
>>The stream MAY indicate additional media formats, not listed in the
>>corresponding stream in the o
vijay wrote:
> Hi,
>
> a snippet from 3311:
>If a UA receives a non-2xx final response to a UPDATE, he session
> parameters MUST remain unchanged, as if no UPDATE had been issued.
> Note that,
> as stated in Section 12.2.1 of RFC 3261 [1], if the non-2xx final
> response is a
> 481 (Call/Tra
gt;
>
> -Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: Sun 8/9/2009 2:48 AM
> To: Manoj Priyankara [TG]
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] SIP OPTIONS
>
>
>
> Manoj Priyankara [TG] wr
Manoj Priyankara [TG] wrote:
> Dear All,
>
> According to the RFC 3261, SIP OPRIONS message should be used to query
> the statue of other UAC or the UAS. Is it OK to use the OPTIONS as a
> keep alive message to know whether the UAS is alive?
>
> Is it necessary to send the OPTIONS message from
Olle E. Johansson wrote:
> 6 aug 2009 kl. 12.49 skrev Vivek Batra:
>
Greetings,
I am wondering if the below scenario is valid or not.
<-- 183 (with SDP) then,
<-- 180 (without SDP)
>>> Yes it's.
>>> However it depends in UAC behaviour on how to render it to the human
>>>
I just saw this thread. Thanks Mikael for your response. Its the best
one available for this case, assuming (as the original poster has
confirmed) that this is all one dialog.
If there is early media flowing, you probably don't want to preempt it
with a generated ringback. But if there is no me
Iñaki Baz Castillo wrote:
> 2009/8/4 Dale Worley :
>> Some SIP systems will not accept INVITEs from phones that are not
>> registered with the system. This is not a requirement of SIP, but it
>> appears that your system enforces this requirement.
>>
>> In regard to the specific "487" response, i
I can understand how you might dislike the unusual way that forking of
subscribes is handled. It is a special case. It was done that way
because there was a desire to support forking of subscribe, and also a
desire not to institute a transaction state machine for subscribe (akin
to the one for
Brett Tate wrote:
> Race conditions exists (although not likely to occur) where the remote
> party's Contact may be updated between sending requests again with update
> auth headers. Depending upon loose routing usage, this can impact Route
> header or request-uri (see rfc3261 section 16.12.1
Rajani wrote:
> In SDP body for each media line we have its media attribute values set below
> the media line. Each of them have default values if its not mentioned
> explicitly in the body..
>
>"If an offered media stream is
>listed as sendrecv (or if there is no direction attribute at
friend friend wrote:
> Dear somesh,
> In hold condition, i set the media ip address as 0 and i set the
> attribute as send only.
> is this enough? am not setting the port as 0.
>
> and could you please tell me, when shall i use Inactive and send only
>
> please advice me.
please rea
ists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Paul Kyzivat
> Sent: Tuesday, June 30, 2009 6:50 PM
> To: Manoj Priyankara [TG]
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Call Transfer through a SIP
Manoj,
Virtually none of the terms you use below have well defined meanings in
sip standards. Many people use such terms, but AFAIK there are not well
understood and consistent implementations for them. So it is not
possible to answer your question as posed.
Tell us whether your SS and IP-PBX
There is a trunk-group parameter defined for the tel uri.
(Can be used in sip uri when it contains a phone number.)
I forget what RFC it is. Would that be what you are looking for?
Paul
Aniruddha Vaidya wrote:
> Hello Everyone,
>
> I have a requirement wherein a Redirect server needs to
Linking of registration to authorization of sessions is an IMS concept.
You will need to ask this question in some IMS forum.
As far as IETF is concerned, the presence, coming, or going of
registrations has *no* bearing on extablished sessions, or on the
ability to establish new sessions.
Sreenath,
I'm puzzled by how you are asking this question.
In general the form of the user part of a sip URI should only be of
concern to the owner of the domain of that URI.
So in sip:VoiceMail;userparam=12...@wcom.com,
it is up to the owner of wcom.com to decide which user parts it is
willing
There is nothing wrong with that as long as wcom.com is happy with it.
Regards,
Paul
Sudhir Kumar Reddy wrote:
> Hi All,
>
> Can I consider following request-uri?
>
> INVITE sip:VoiceMail;userparam=12...@wcom.com SIP/2.0
>
> any response is highly appericated
>
> Thanks in adv
Certainly things of this sort could be useful.
At least for now such things are in the realm of "products" rather than
standards-based stuff.
Blocking of call delivery based on presence status does require a
significant degree of trust in the accuracy of the presence status. When
in doubt I thi
Iñaki Baz Castillo wrote:
> Thanks for so great explanation.
>
> However, I wonder why so many new features are needed when most of the
> devices
> don't implement XCAP yet. The fact I don't consider useful all the new
> features described above. Is it really implemented "somewhere"?
I susp
Victor Pascual Ávila wrote:
> Hi Paul,
> thanks for your comments. See responses inline.
>
> 2009/6/11 Paul Kyzivat :
>> There is really no particular value in using session timers in this case.
>> Session timer is for the benefit of record-routed proxies.
>
>
Iñaki Baz Castillo wrote:
> El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió:
>> In one case I have a single phone with one phone number. Typically if a
>> 2nd call comes in while phone is in use it is signaled to the callee in
>> the media stream rather than thro
Iñaki Baz Castillo wrote:
> El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió:
>> Specifically, from a caller perspective, how is a call handled via "call
>> waiting" at the callee any different from the call ringing on a phone
>> with two lines where the other
Agree with Attila. So in the given circumstance the UAS could have
responded to the invite with a 488 to indicate that it didn't support
the offered media.
Another possibility is for the UAS to return an answer where the port in
the m-line is zero, thus rejecting the media stream since it can't
There is really no particular value in using session timers in this
case. Session timer is for the benefit of record-routed proxies.
If a UA suspects that there might be a problem it can test the signaling
path by sending an in-dialog message. It could be reINVITE, or UPDATE,
or OPTIONS. OPTION
This special treatment for "call waiting" has always baffled me.
It seems to be rooted in the telco partitioning of services rather than
on any fundamental difference.
Specifically, from a caller perspective, how is a call handled via "call
waiting" at the callee any different from the call ring
Iñaki Baz Castillo wrote:
> El Miércoles, 10 de Junio de 2009, Paul Kyzivat escribió:
>
>> Actually, *in theory*, you can put Accept-Language:es into your INVITE,
>> and then the text messages in the response ought to be written in Spanish.
>>
>> (And of course
Iñaki Baz Castillo wrote:
> El Miércoles, 10 de Junio de 2009, Dale Worley escribió:
>> And a UAC might want to display the reason phrase, so you could use
>
> Do you mean that the UAC could display the reason phrase in *English*? IMHO a
> standarized code or "string" should be needed for this
This discussion has all assumed MESSAGE.
If you want to send big messages, use MSRP.
Then they can be as big as you like. Multi-GB messages were considered
when designing it.
Paul
Victor Pascual Ávila wrote:
> Iñaki,
>
> On Fri, Jun 5, 2009 at 11:56 AM, Iñaki Baz Castillo wrote:
>> 2009
t *will*, but it MAY.
Thanks,
Paul
> Thanks and regards,
>
> Shamik Saha
> Project Engineer
> Voice Protocols
> Cell : +91-9886704155
>
> -----Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: Thursday, June 04, 2009 9:05 PM
&g
nal Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Paul Kyzivat
> Sent: 03 June 2009 16:42
> To: shamik.s...@wipro.com
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implem
Good answers.
Also look at
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-10.txt
Paul
Attila Sipos wrote:
> yes, the call flow is fine.
>
> But I can understand why you are confused.
> The important part is this:
> For this specification, that is
>
A significant limitation in what you propose is that it requires Bob to
have a public key that Alice knows. In general we don't find that to be
the case in most telephony applications.
Thanks,
Paul
Vadim Lebedev wrote:
> I see,
> Well this particular attack could be prevented by
It wasn't stated who is doing the reinvite, and that can make a difference.
Also, there is nothing special about a reinvite used for session timer
refresh vs any other reinvite. Only the sender of the reinvite knows why
it was sent, and reinvites that are primarily for some other purpose
also r
I would just put a different spin on this without changing the facts:
If you *don't* terminate the subscription with your NOTIFY, then by
definition it is not the last NOTIFY, because the subscription still has
to be terminated sometime, and that will entail a NOTIFY.
So, if you sent a NOTIFY a
cool goose wrote:
> Thanks All for pointing me towards some resources. I have never written any
> protocol stacks before except for few small SIP tools. This would be my
> first time writing a SIP stack and that's where I felt a need for some
> literature or books on designing protocol stacks. An
A plausible case is when the call is forked, and there are 180 responses
from multiple forks. The UAC may then be able to determine from the
answer SDP that one of the early dialogs is undesirable - lacks features
it wants. So it sends a BYE to that one while allowing the other to
continue ring
A callee capability of "isfocus" on the contact header field of the far
end tells you that it is a conference focus. E.g.
Contact: sip:al...@atlanta.example.com;isfocus
Paul
wen ren wrote:
> hi, all
> recently I am implement some complex features about conference. usually
> the con
bahan...@hotmail.de wrote:
> Hi,
>
>
> I am sorry. Same Email with Subject.
>
> I am newcomer in SIP and Kamailio Wold an have a question.
>
> I have two IP Telefones and would like to realize with Kamailio
What is Kamailio?
> an IP Communication. The Problem:
>
> a. The UA 1 calls UA
Dale Worley wrote:
> On Tue, 2009-05-12 at 08:47 +0200, Damir Reic wrote:
>> If UAS receives BYE on early dialog and answers it with 200OK, does it have
>> to respond to initial invite with 487 (same as CANCEL was received)?
>
> In RFC 3261 section 15.1.2, it says:
>
>The UAS MUST still res
I agree with Dale. In addition, having the UAC do it this way makes the
downstream behavior the same whether the recursion on the 300 is done by
the UAC or by a proxy on the path.
Thanks,
Paul
Dale Worley wrote:
> On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera w
Its also possible for the proxy to recurse on some of the alternatives,
and then return a 300 containing some that it chose not to try itself.
But an all-or-nothing approach by the proxy is much more likely.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> El Miércoles, 6 de Mayo de 2009
Iñaki Baz Castillo wrote:
> 2009/5/5 Paul Kyzivat :
>> Iñaki Baz Castillo wrote:
>>
>>> Please Bob, read the *oficially* reported bug about this subject which
>>> had a long discussion some time ago:
>>> http://bugs.sipit.net/show_bug.cgi?id=775
>
Iñaki Baz Castillo wrote:
> 2009/5/5 Bob Penfield :
>> If there are no binding remaining, the 200 OK does not need to have a
>> Contact header. A 200-OK response without any Contacts indicates that there
>> are no bindings.
>
> Please Bob, read the *oficially* reported bug about this subject w
Stephen,
I think you have arrived at the correct interpretation. In general it is
*permitted*, but in most cases it is a bad idea. The cases where it
might be reasonable are when the new transaction renders moot the
outcome of the earlier transactions still in flight.
You should *never* assume
Krishna Rao Gurram wrote:
> Scenario:-
> UAS receives Invite with SDP.
> Application above UAS sends 100 Trying
> Application now sends 180 without SDP and with 100 rel.
> UAS receives PRACK with SDP for 180.
> Here what is the behavior of UAS? How
In a topology such as shown below, you don't need an extra media relay
to enforce your billing - you have the gateway, which is already
terminating the media. Why aren't you doing the billing there?
Paul
Iñaki Baz Castillo wrote:
> 2009/4/29 Alex Balashov :
>> What I meant before was th
This isn't really the best place to discuss the logic behind IMS
designs. While I have some knowledge of that, I'm not actively involved,
and I find much of what is there to be strange.
Good Luck
Paul
Dushyant Dhalia wrote:
> Paul Kyzivat wrote:
>>
>>
Dushyant Dhalia wrote:
> In 3GPP specs, related to IMS procedure, it's written that P-CSCF sends
> the SUBSCRIBE request to I-CSCF which in turns finds the address of
> S-CSCF through Cx query. My question is why can't P-CSCF send the
> SUBSCRIBE directly to S-CSCF using Service-Route it recei
It seems that usually people who ask about billing assume that something
in the signaling path can just generate billing records at start and end
of call, or save some data from start of call and generate a CDR when
the call ends.
But that is naive. If you are only on the signaling path, not th
Scott Lawrence wrote:
> On Mon, 2009-04-27 at 02:22 +0800, Avasarala Ranjit-A20990 wrote:
>> Hi
>>
>> I do not think a SIP entity can return a 302 response with contact
>> containing "mailto:"; because SIP is not a email protocol like SMTP. So I
>> feel its an error to receive "mailto: in Contact
These are interesting cases. I think they go beyond what is specified,
and hence are subject to creative implementation, which in this case is
probably a bad thing.
I agree with the opinion that this should be treated much like an
INVITE. In particular,
- the request should be routed to a desti
I disagree with the notion that you should include C-T:application/sdp
and C-L:0 to indicate no offer. In fact, I think it is probably invalid
to do so.
There are at least a couple of issues with that:
- If you specify a C-T, then the body needs to conform to the
specification for that type. I
shamik.s...@wipro.com wrote:
> Hi Brett,
>
> In section 4 it is said that
>
> " Dialogs come into existence along with their first usage. Dialogs
>terminate when their last usage is destroyed. The messages that
>create and destroy usages vary per usage. This section provides a
>h
601 - 700 of 1159 matches
Mail list logo
