Andy,
What you describe sounds very much like a transaction stateful proxy,
except you seem not to plan on inserting a Via header.
If you follow the specification for a proxy fully then most of what you
need to do has been carefully worked out. If you try to invent a new
component with different characteristics, then you must solve all the
problems that causes. If you want help from the IETF to do that you need
to make a convincing case that it is a problem that needs to be solved.
Paul
Andy Pandaram wrote:
Jeroen,
Thanks a lot for your emails. Let us say the call distributor hands off
these INVITEs to UAs (and not proxies), then the UA can directly send
the response to the UAC, say 180 or 200 with its own Contact header. In
such a case, the PRACK (for 180) or ACK for 200 Ok, would directly reach
the UA. A re-transmitted INVITEs would also get routed to same UA (until
the distributor maintains the state). Would such an approach work for
TCP as well? Or in cases of TCP the ACK would still have to go thorugh
the distributor and later the UAS should send an UPDATE to change the port?
If some clients do use same call-id, but different From tags, they would
end up being routed to the same UA which would maintain full state and
can distinguish them as seperate calls.
By looking at just the call-id, the distributor need not do a full SIp
decoding and also need not maintain too much state.
Thanks
Andy
*/Jeroen van Bemmel <[EMAIL PROTECTED]>/* wrote:
On second thought, you'd better include the from-tag too (if
present), it
adds some extra protection against buggy clients that use not-so-random
call-ids (though not foolproof).
If your proxies are such that they set to-tags by which the proxy
instance
can be recognised, you can also consider to use that as primary or
fallback
routing mechanism for subsequent requests. Requests after the first
INVITE
(say PRACK) will contain such a to-tag identifying the proxy that
initially
answered. In addition, you can cache the to-tag you find in a
response to
route subsequent requests (without a need for the identifying aspect of
to-tags, but drawback that it means you need to keep state at the
distributor)
Jeroen
> Hi Andy,
>
> In theory I would say: yes, Call-Id would be sufficient
>
> The complete dialog-id consists of from-tag + call-id + to-tag,
the to-tag
> is not set yet and the caller could send multiple INVITEs with
the same
> call-id but different from tags. Consequence would be that all
these calls
> get routed to the same proxy, but that seems reasonable to me
>
> An issue that will occur is: at which point will you remove the
state in
> the distributor (i.e. the mapping of call-id to the selected proxy)?
> Perhaps upon reception of a response containing a Contact header,
but then
> what about retransmitted INVITEs / PRACKS etc that arrive after
that? You
> would probably need to set a timer and wait for 32 seconds after
> forwarding the response with the contact header
>
> Jeroen
>
> ----- Original Message -----
> From: "Andy Pandaram"
> To: "Paul Kyzivat"
> Cc:
> Sent: Thursday, June 30, 2005 8:28 AM
> Subject: Re: [Sip-implementors] Using call-id for SIP call
distribution
>
>
>> The call distributor only distributes incoming SIP calls among
multiple
>> proxies or may be even SIP UAs (like a SIP-PSTN GW). The SIP-GWs
would
>> listen on non-standard ports. The call distributor would receive
INVITEs
>> etc on port 5060 and send them to the SIP GW which may be
listening on
>> port 10,000. Now, the re-transmitted INVITEs would still come to
the call
>> distributor. And also until the SIP GW can give its new contact
in the
>> 200 Ok or possibly in an UPDATE, subsequent requets (like PRACK)
might
>> come through the call distributor. In such cases, the
distributor would
>> need to send the subsequent requests to the same GW (as the
first INVITE
>> was sent to). Now, for this purpose, is it enough that the
distributor
>> looks at just the Call-Id and not other tags and parameters?
>>
>> Thanks
>> Andy
>>
>>
>> Paul Kyzivat wrote:
>>
>>
>> Andy Pandaram wrote:
>>> Hi,
>>>
>>> If a SIP call distributor has to send incoming calls to
multiple SIP
>>> proxies, is it enough to just look at the Call-Id (since that
must be
>>> unique across space and time)? Is there any reason for the
distributor
>>> to look at From/To Tags/Via branch etc?
>>
>> What is a SIP call distributor?
>>
>> If it is a proxy then 3261 should tell you all you need to know.
>>
>> Paul
>>
>>> Thanks
>>> Andy
>>>
>>>
>>> ---------------------------------
>>> Too much spam in your inbox? Yahoo! Mail gives you the best spam
>>> protection for FREE!
>>> http://in.mail.yahoo.com
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>
>>
>> ---------------------------------
>> Free antispam, antivirus and 1GB to save all your messages
>> Only in Yahoo! Mail: http://in.mail.yahoo.com
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------------------------------------------------
How much free photo storage do you get? Store your friends n family
photos for FREE with Yahoo! Photos.
http://in.photos.yahoo.com
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
