On 6/26/06, Fredrik Thulin <ft at it.su.se> wrote:
Hi
I have a question on bridged line appearance with a state agent.
When the state agent sends it's SUBSCRIBE to a newly registered UA, that
UA answers the SUBSCRIBE and then sends a SUBSCRIBE in the other
direction. I have only read the draft semi-carefully, but I haven't
understood what it is that makes the state agent know what Bridged Line
Appearance that SUBSCRIBE is intended for. I'm talking about this
moment in the establishment of the dual-SUBSCRIBEs :
F9 Alice ----> State Agent
SUBSCRIBE sip:sa at stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP
ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice at example.com>;tag=925A3CAD-CEBB276E
To: <
sip:sa at stateagent.example.com>
How does the state agent know that this SUBSCRIBE is about
sip:alice at example.com, and not
sip:some-other-bla at example.com?
Is it the Contact the state agent used in F5 that is really unique to
this particular BLA? If so, I would suggest showing this more clearly
by letting the state agent use Contact:
<sip:alice-at-example.com at stateagent.example.com> or similar, instead
of <sip:sa at stateagent.examle.com
>.
[Venkatesh]: Yes, that is correct. 01 version of this draft had example message flows providing unique contact information per subscription. It was suggested in the mailing list that such message flows made it harder for people to read these messaging flows and we were recommended to change the same.
Also, a couple of comments :
* Maybe the reg-event NOTIFY from the registrar to the state agent
should be shown in the section 6.1.1 and 6.1.2 diagrams? Now, one may
wonder how the state agent knows it should send a SUBSCRIBE.
[Venkatesh]: Section 5 of the draft covers the discovery aspect. It indicates how the state-agent gets notified of registrations. We chose to omit indicating of the flow of reg_event messages in the ladder diagrams to keep it simple. We will definitely consider introducing these additional messages in the next version if the same is considered useful by others in the mailing list as well.
* You have many SIP headers where long headers are wrapped. That's OK
but you have to start the next line with whitespace, for example :
Change
Via: SIP/2.0/UDP
stateagent.example.com;branch=z9hG4bK1846984327225734
into
Via: SIP/2.0/UDP
stateagent.example.com;branch=z9hG4bK1846984327225734
[Venkatesh]: Will change this in the next revision of the draft.
* In message "F13 Bob ----> State Agent" (section 6.1.2), the To: is
<
sip:alice at stateagent.example.com>. Where does that address come from?
I suspect a typo. alice at stateagent then appears in lots of other
messages too.
[Venkatesh]: Thanks for pointing this one out. We will fix this in the next revision as well.
/Fredrik
_______________________________________________
Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP