On Thu, 2009-06-11 at 14:41 -0500, Brad Johnson wrote:
> The scenario I am talking about is when multiple phones behind our proxy
> are registered to an external registrar. Our proxy rewrites the
> registration Contacts from the phone's private address:port to a public
> address:port on our prox
So we should append a "received" parameter containing our public
address:port to outbound Register requests, or to all requests?
If there are many proxies between the phones and the registrar, only the
proxy closest to the phones does any forking of inbound Invites, correct?
How do we know when w
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 through "ring". To switch betwee
El Jueves, 11 de Junio de 2009, Brad Johnson escribió:
> The scenario I am talking about is when multiple phones behind our proxy
> are registered to an external registrar. Our proxy rewrites the
> registration Contacts from the phone's private address:port to a public
> address:port on our proxy's
The scenario I am talking about is when multiple phones behind our proxy
are registered to an external registrar. Our proxy rewrites the
registration Contacts from the phone's private address:port to a public
address:port on our proxy's WAN interface. The external registrar then
has multiple Co
On Thu, 2009-06-11 at 14:19 -0500, Brad Johnson wrote:
> So if proxies do not register multiple bindings using unique public
> ports in the Contact, how do they distinguish to which phone an inbound
> Invite should go?
All of them, as a rule.
The registration binds some AOR (sip:xmlsc...@exampl
So if proxies do not register multiple bindings using unique public
ports in the Contact, how do they distinguish to which phone an inbound
Invite should go?
Thanks,
Brad
Scott Lawrence wrote:
> On Thu, 2009-06-11 at 10:49 -0500, Brad Johnson wrote:
>
>> I am trying to figure out the proper
On Thu, 2009-06-11 at 10:49 -0500, Brad Johnson wrote:
> I am trying to figure out the proper behavior when multiple SIP phones
> are registered with the same URI account.
> With our own SIP Proxy implementation, we map registrations from the
> phones private contact address and port to our own p
The RFC is also emphasis not to propagate "stray" 408 response. In
your case, if the proxy has client-transaction, it should terminate it
and propagate the response else it should drop it.
Thus, if the UAS is sending 408 within the duration of NIS, it will be
propagated.
On Thu, Jun 11, 2009 at 9:
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 through "ring". To switch between calls you
> typically use "flas
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 line is in use? Why should the
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
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 line is in use? Why should the caller get
> a special signal in
Any suggestions?
On Wed, Jun 10, 2009 at 7:08 PM, Pandurangan R
S wrote:
> Hi,
>
> I have a query related to RFC 4320 (Addressing issues identified with
> non-invite transactions)
>
> RFC 4320 states that an element will not forward 408 response upstream
> as it is always useless. This is true.
>
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 am trying to figure out the proper behavior when multiple SIP phones
are registered with the same URI account.
With our own SIP Proxy implementation, we map registrations from the
phones private contact address and port to our own public address and a
unique public port for each phone. This al
El Jueves, 11 de Junio de 2009, Attila Sipos escribió:
> >>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 b
El Jueves, 11 de Junio de 2009, kishore sowdi escribió:
> I have one more question -
> "how to tell the presence server that UE does'nt want presence
> server to send NOTIFY's
> and how to start receiving NOTIFY's after this?"
> Any XCAP rf for this ?..
Again:
RFC 4825 -- XML Configuration Acce
There is one more method we can use if we are not supporting session-timers. If
both UAC and UAS are terminating the media, it can check for the MEDIA_TIMEOUT
( Idle for some duration ) and taredown the call.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.ed
Thanks Victor
//
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Victor
Pascual Ávila
Sent: Thursday, June 11, 2009 3:18 PM
To: Manoj Priyankara [TG]
Cc: sip-implementors@lists.cs.columbia.edu
S
On Thu, Jun 11, 2009 at 11:11 AM, Manoj Priyankara
[TG] wrote:
>
> Dear All,
>
> Could one of you please explain me how to handle following situation in
> a SIP session?
>
> Let us imagine that UAC's A and B are in a call and due to a network
> connectivity problem, user A disconnects without sendi
Dear All,
Could one of you please explain me how to handle following situation in
a SIP session?
Let us imagine that UAC's A and B are in a call and due to a network
connectivity problem, user A disconnects without sending any message to
the UAS.
Then the UAS still thinks that UAC A is alive. Of
>>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
24 matches
Mail list logo
