[sip-comm-dev] ResponseEventS dispatching in the SIP service


#1

Hi All,

From Lubomir Marinov's last commit:

Log:
Implements initiating call transfer (in addition to responding to call transfer requests which was introduced in a previous revision). It will still not work because the telephony OperationSet needs to be a Request.NOTIFY method processor but the presence OperationSet will overwrite its registration since only one processor is supported for each type of Request method.

Since I'm in the process of making the SIP service implementation use
a single JAIN-SIP stack whatever the number of SIP accounts registered
is, I have precisely to deal with how to find which a response event
should be dispatched to. How about registering JAIN-SIP's DialogS
processors?

You would have two methods:
- registerDefaultMethodProcessor() used to dispatch incoming new
requests (ie currently unknown JAIN-SIP's DialogS)
- registerDialogProcessor() used to dispatch incoming messages related
to the registered Dialog (for example "NOTIFY presence" would go to
the instance which first sent the "SUBSCRIBE presence" request).

The tricky part would be to unregister the DialogS. Dialog.getState()
might get used to achieve this.

What do you think of that?

Cheers,

···

On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:

--
Sébastien Mazy


#2

Hey Sébastien,

Emil and I have been looking at a few approaches to the problem of
registering method processors and figuring out which one is meant for
a given event. They aren't very different and revolve around the idea
of:

- allowing multiple method processors for a given method, and

- letting the processors signal whether they've consumed a specific
event so that it wouldn't be delivered to the other processors for the
same method.

The last one the two of us discussed was introducing a substitute for
SipListener in the context of method processors which would have the
same methods as SipListener but they would return an indicator
signaling whether the event given to the processRequest/Response/etc
method was consumed by the processor.

This way both the presence and telephony OperationSets would be able
to register as method processors of the Request.NOTIFY method. The
presence OperationSet will state in the return value of its
processRequest method that it has handled the RequestEvent when the
event question is of method Request.NOTIFY and has Event header value
of "presence" and will mark the RequestEvent of method Request.NOTIFY
and with Event header value of "refer" unhandled for the telephony
OperationSet to handle.

Regards,
Lubo

···

On Mon, Aug 25, 2008 at 1:30 PM, Sébastien Mazy <sebastien.mazy@insa-lyon.fr> wrote:

Hi All,

From Lubomir Marinov's last commit:

On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:

Log:
Implements initiating call transfer (in addition to responding to call transfer requests which was introduced in a previous revision). It will still not work because the telephony OperationSet needs to be a Request.NOTIFY method processor but the presence OperationSet will overwrite its registration since only one processor is supported for each type of Request method.

Since I'm in the process of making the SIP service implementation use
a single JAIN-SIP stack whatever the number of SIP accounts registered
is, I have precisely to deal with how to find which a response event
should be dispatched to. How about registering JAIN-SIP's DialogS
processors?

You would have two methods:
- registerDefaultMethodProcessor() used to dispatch incoming new
requests (ie currently unknown JAIN-SIP's DialogS)
- registerDialogProcessor() used to dispatch incoming messages related
to the registered Dialog (for example "NOTIFY presence" would go to
the instance which first sent the "SUBSCRIBE presence" request).

The tricky part would be to unregister the DialogS. Dialog.getState()
might get used to achieve this.

What do you think of that?

Cheers,

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Sebastien,

We just had a quick offline chat with Lubomir on this. We are probably
going to make the method processors have an interface of their own
rather than using SipListeners. This way we'll be able to register
several processors for the same sip method. The new interface will also
provide them with a way to indicate whether they have handled a
particular event or not. (I actually see now that he has already
explained this)

Concerning your registerDialogProcessor() suggestion. Sounds nice but I
am worried about the programming overhead. This would require operation
sets to register themselves as a processor for every dialog they create.
If we are going to use a single port for all accounts then I'd like us
to have all the mux/demux functionality in a single place.

Now, I thought about this since our talk yesterday and here's what I
suggest: both the Dialog and the Transaction interfaces have the
following two methods:

    public void setApplicationData(Object applicationData);
    public Object getApplicationData();

They are meant for applications to tag dialogs and transaction with
stateful, dialog/transaction dependent information. I think we could
easily implement all muxing/demuxing with them. We can even make them
almost transparent for the rest of the application. We just need to make
sure that all dialogs and transactions get tagged with a reference to
the owning SC provider when they are created. It would probably also be
a good idea to make sure that no dialogs nor transactions can be created
within SC without attaching the corresponding tag. We would probably
need to restrict access to the jain sip providers in order to achieve this.

Concerning server dialogs and transactions (i.e. the ones that are going
to be initiated by our interlocutors or servers). You can set their
application data in the message dispatcher that you mentioned yesterday.
How exactly we are going to determine which provider an incoming dialog
or tran are meant for, is a different story. Ideally the To header
should contain our registration address and this is probably going to be
enough in the majority of the cases.

I am quite certain that we're still going to run into cases where this
is not going to be enough but I believe we can limit them to a
reasonably low number.

What do you think?

Cheers
Emil

Sébastien Mazy написа:

···

Hi All,

From Lubomir Marinov's last commit:

On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:

Log:
Implements initiating call transfer (in addition to responding to call transfer requests which was introduced in a previous revision). It will still not work because the telephony OperationSet needs to be a Request.NOTIFY method processor but the presence OperationSet will overwrite its registration since only one processor is supported for each type of Request method.

Since I'm in the process of making the SIP service implementation use
a single JAIN-SIP stack whatever the number of SIP accounts registered
is, I have precisely to deal with how to find which a response event
should be dispatched to. How about registering JAIN-SIP's DialogS
processors?

You would have two methods:
- registerDefaultMethodProcessor() used to dispatch incoming new
requests (ie currently unknown JAIN-SIP's DialogS)
- registerDialogProcessor() used to dispatch incoming messages related
to the registered Dialog (for example "NOTIFY presence" would go to
the instance which first sent the "SUBSCRIBE presence" request).

The tricky part would be to unregister the DialogS. Dialog.getState()
might get used to achieve this.

What do you think of that?

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

hi,
i have been trying to give shape to the sip communicator frame. i am using com.sun.awt.AWTUtilities which works fine for other things. anyhow, this is what i have done:

in the class SIPCommFrame.java, i have modified the setVisible method as following:

public void setVisible(boolean isVisible)
{
if (isVisible)
{
this.pack();
this.setSizeAndLocation();

        try
        \{
            
            com\.sun\.awt\.AWTUtilities\.setWindowOpacity\(this, 0\.5f\);
            com\.sun\.awt\.AWTUtilities
            \.setWindowShape\(this, new Ellipse2D\.Double\(0, 0, this
                    \.getWidth\(\), this\.getHeight\(\)\)\);
                           
        \}
        catch\(Exception ex\)
        \{
           
        \}
        this\.ensureOnScreenLocationAndSize\(\);
    \}

    super\.setVisible\(isVisible\);
\}

now, the translucenry works fine. so it means the class is com.sun.awt.AWTUtilities is imported properly and without error. but i can not seem to apply shape to the window in any way.

any idea what i am missing?

regards,

khan


#5

If Dialog.getApplicationData/setApplicationData is to be used, please
note that I use it in
net.java.sip.communicator.impl.protocol.sip.DialogUtils.

Thanks,
Lubo

···

On Mon, Aug 25, 2008 at 2:37 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Sebastien,

We just had a quick offline chat with Lubomir on this. We are probably
going to make the method processors have an interface of their own
rather than using SipListeners. This way we'll be able to register
several processors for the same sip method. The new interface will also
provide them with a way to indicate whether they have handled a
particular event or not. (I actually see now that he has already
explained this)

Concerning your registerDialogProcessor() suggestion. Sounds nice but I
am worried about the programming overhead. This would require operation
sets to register themselves as a processor for every dialog they create.
If we are going to use a single port for all accounts then I'd like us
to have all the mux/demux functionality in a single place.

Now, I thought about this since our talk yesterday and here's what I
suggest: both the Dialog and the Transaction interfaces have the
following two methods:

   public void setApplicationData(Object applicationData);
   public Object getApplicationData();

They are meant for applications to tag dialogs and transaction with
stateful, dialog/transaction dependent information. I think we could
easily implement all muxing/demuxing with them. We can even make them
almost transparent for the rest of the application. We just need to make
sure that all dialogs and transactions get tagged with a reference to
the owning SC provider when they are created. It would probably also be
a good idea to make sure that no dialogs nor transactions can be created
within SC without attaching the corresponding tag. We would probably
need to restrict access to the jain sip providers in order to achieve this.

Concerning server dialogs and transactions (i.e. the ones that are going
to be initiated by our interlocutors or servers). You can set their
application data in the message dispatcher that you mentioned yesterday.
How exactly we are going to determine which provider an incoming dialog
or tran are meant for, is a different story. Ideally the To header
should contain our registration address and this is probably going to be
enough in the majority of the cases.

I am quite certain that we're still going to run into cases where this
is not going to be enough but I believe we can limit them to a
reasonably low number.

What do you think?

Cheers
Emil

Sébastien Mazy написа:

Hi All,

From Lubomir Marinov's last commit:

On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:

Log:
Implements initiating call transfer (in addition to responding to call transfer requests which was introduced in a previous revision). It will still not work because the telephony OperationSet needs to be a Request.NOTIFY method processor but the presence OperationSet will overwrite its registration since only one processor is supported for each type of Request method.

Since I'm in the process of making the SIP service implementation use
a single JAIN-SIP stack whatever the number of SIP accounts registered
is, I have precisely to deal with how to find which a response event
should be dispatched to. How about registering JAIN-SIP's DialogS
processors?

You would have two methods:
- registerDefaultMethodProcessor() used to dispatch incoming new
requests (ie currently unknown JAIN-SIP's DialogS)
- registerDialogProcessor() used to dispatch incoming messages related
to the registered Dialog (for example "NOTIFY presence" would go to
the instance which first sent the "SUBSCRIBE presence" request).

The tricky part would be to unregister the DialogS. Dialog.getState()
might get used to achieve this.

What do you think of that?

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hey Sebastien,

I just had a quick chat with Enrico Marocco from Telecom Italia Labs
about the algorithm that we can use when demux-ing incoming, dialog
initiating requests.

According to him, using the source address of the datagram/packet as a
condition is not a good idea as it is based on anything in the RFC. I
tend to agree with this and besides I am now thinking that the fact that
a request came from your proxy could mean that it is trying to contact a
registrarless (P2P) account on your machine for example. In other words,
scratch the proxy condition.

Enrico also suggesting having a look at the use part of the request URI
in addition to analysing the whole URI. Here's what this gives us:

1. Check if the TO header matches any of our AORs
2. Check if the Request URI matches any of our AORs
3. Check if the user part of the request URI matches the user part of
any of our AORs
4. Forward to a default account.

Does this make sense?

Emil

Emil Ivov написа:

···

Hey Sebastien,

We just had a quick offline chat with Lubomir on this. We are probably
going to make the method processors have an interface of their own
rather than using SipListeners. This way we'll be able to register
several processors for the same sip method. The new interface will also
provide them with a way to indicate whether they have handled a
particular event or not. (I actually see now that he has already
explained this)

Concerning your registerDialogProcessor() suggestion. Sounds nice but I
am worried about the programming overhead. This would require operation
sets to register themselves as a processor for every dialog they create.
If we are going to use a single port for all accounts then I'd like us
to have all the mux/demux functionality in a single place.

Now, I thought about this since our talk yesterday and here's what I
suggest: both the Dialog and the Transaction interfaces have the
following two methods:

    public void setApplicationData(Object applicationData);
    public Object getApplicationData();

They are meant for applications to tag dialogs and transaction with
stateful, dialog/transaction dependent information. I think we could
easily implement all muxing/demuxing with them. We can even make them
almost transparent for the rest of the application. We just need to make
sure that all dialogs and transactions get tagged with a reference to
the owning SC provider when they are created. It would probably also be
a good idea to make sure that no dialogs nor transactions can be created
within SC without attaching the corresponding tag. We would probably
need to restrict access to the jain sip providers in order to achieve this.

Concerning server dialogs and transactions (i.e. the ones that are going
to be initiated by our interlocutors or servers). You can set their
application data in the message dispatcher that you mentioned yesterday.
How exactly we are going to determine which provider an incoming dialog
or tran are meant for, is a different story. Ideally the To header
should contain our registration address and this is probably going to be
enough in the majority of the cases.

I am quite certain that we're still going to run into cases where this
is not going to be enough but I believe we can limit them to a
reasonably low number.

What do you think?

Cheers
Emil

Sébastien Mazy написа:

Hi All,

From Lubomir Marinov's last commit:

On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:

Log:
Implements initiating call transfer (in addition to responding to call transfer requests which was introduced in a previous revision). It will still not work because the telephony OperationSet needs to be a Request.NOTIFY method processor but the presence OperationSet will overwrite its registration since only one processor is supported for each type of Request method.

Since I'm in the process of making the SIP service implementation use
a single JAIN-SIP stack whatever the number of SIP accounts registered
is, I have precisely to deal with how to find which a response event
should be dispatched to. How about registering JAIN-SIP's DialogS
processors?

You would have two methods:
- registerDefaultMethodProcessor() used to dispatch incoming new
requests (ie currently unknown JAIN-SIP's DialogS)
- registerDialogProcessor() used to dispatch incoming messages related
to the registered Dialog (for example "NOTIFY presence" would go to
the instance which first sent the "SUBSCRIBE presence" request).

The tricky part would be to unregister the DialogS. Dialog.getState()
might get used to achieve this.

What do you think of that?

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi fellow devs!

I'm the GSoC student responsible for implementing SC's SIP File Transfer.
Currently the file-transfer is implemented with issues, i would describe it
as a liana bridge, you can use it, but definitely there is space for
improvement.

Anyway, for the file transfer purposes i needed to allow multiple
OperationSets [OperationSetBasicTelephony and
OperationSetFileTransferSipImpl] to register on the provider so that i could
process the incoming SIP INVITE requests that it's how the file transfer is
negotiated. So, basicly i ended up registering both operation sets so that
both of them get called when there is an INVITE and what i did was that on
the processRequest, i checked the body of the incoming SDP offer to see if
it had a 'file-selector' attribute, if it did the processRequest of the
OperationSetFileTransferSipImpl continued processing the INVITE, if it
didn't then OperationSetBasicTelephony would take care of it.

That solution has a problem inherent to it because supposedly the SDP body
could have multiple media lines and multiple kinds of sessions so that one
could negotiate, with the same invite, a call and a file transfer, therefore
the end result is that such mixed sessions only get processed for their file
transfer (because they must have the file-selector) attribute.

I'm not sure if this changes anything in the problem being discussed or in
the solution, i just felt obliged to write about this variable to warn you
about this need.

My solution proposal to support these kind of mixed sessions would be to
somehow abstract the OperationSets from the SIP protocol and only make them
add or remove things in the SDP.

I apologise if i eventually only added noise to the discussion.

Regards,
João Antunes

···

On Mon, Aug 25, 2008 at 12:45 PM, Lubomir Marinov <lubomir.marinov@gmail.com > wrote:

If Dialog.getApplicationData/setApplicationData is to be used, please
note that I use it in
net.java.sip.communicator.impl.protocol.sip.DialogUtils.

Thanks,
Lubo

On Mon, Aug 25, 2008 at 2:37 PM, Emil Ivov <emcho@sip-communicator.org> > wrote:
> Hey Sebastien,
>
> We just had a quick offline chat with Lubomir on this. We are probably
> going to make the method processors have an interface of their own
> rather than using SipListeners. This way we'll be able to register
> several processors for the same sip method. The new interface will also
> provide them with a way to indicate whether they have handled a
> particular event or not. (I actually see now that he has already
> explained this)
>
> Concerning your registerDialogProcessor() suggestion. Sounds nice but I
> am worried about the programming overhead. This would require operation
> sets to register themselves as a processor for every dialog they create.
> If we are going to use a single port for all accounts then I'd like us
> to have all the mux/demux functionality in a single place.
>
> Now, I thought about this since our talk yesterday and here's what I
> suggest: both the Dialog and the Transaction interfaces have the
> following two methods:
>
> public void setApplicationData(Object applicationData);
> public Object getApplicationData();
>
> They are meant for applications to tag dialogs and transaction with
> stateful, dialog/transaction dependent information. I think we could
> easily implement all muxing/demuxing with them. We can even make them
> almost transparent for the rest of the application. We just need to make
> sure that all dialogs and transactions get tagged with a reference to
> the owning SC provider when they are created. It would probably also be
> a good idea to make sure that no dialogs nor transactions can be created
> within SC without attaching the corresponding tag. We would probably
> need to restrict access to the jain sip providers in order to achieve
this.
>
> Concerning server dialogs and transactions (i.e. the ones that are going
> to be initiated by our interlocutors or servers). You can set their
> application data in the message dispatcher that you mentioned yesterday.
> How exactly we are going to determine which provider an incoming dialog
> or tran are meant for, is a different story. Ideally the To header
> should contain our registration address and this is probably going to be
> enough in the majority of the cases.
>
> I am quite certain that we're still going to run into cases where this
> is not going to be enough but I believe we can limit them to a
> reasonably low number.
>
> What do you think?
>
> Cheers
> Emil
>
>
> Sébastien Mazy написа:
>> Hi All,
>>
>> From Lubomir Marinov's last commit:
>>
>> On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:
>>> Log:
>>> Implements initiating call transfer (in addition to responding to call
transfer requests which was introduced in a previous revision). It will
still not work because the telephony OperationSet needs to be a
Request.NOTIFY method processor but the presence OperationSet will overwrite
its registration since only one processor is supported for each type of
Request method.
>>
>> Since I'm in the process of making the SIP service implementation use
>> a single JAIN-SIP stack whatever the number of SIP accounts registered
>> is, I have precisely to deal with how to find which a response event
>> should be dispatched to. How about registering JAIN-SIP's DialogS
>> processors?
>>
>> You would have two methods:
>> - registerDefaultMethodProcessor() used to dispatch incoming new
>> requests (ie currently unknown JAIN-SIP's DialogS)
>> - registerDialogProcessor() used to dispatch incoming messages related
>> to the registered Dialog (for example "NOTIFY presence" would go to
>> the instance which first sent the "SUBSCRIBE presence" request).
>>
>> The tricky part would be to unregister the DialogS. Dialog.getState()
>> might get used to achieve this.
>>
>> What do you think of that?
>>
>> Cheers,
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>
>


#8

João,

I committed r4346 earlier today which:

- switches from SipListener to MethodProcessor for the purposes of
ProtocolProviderServiceSipImpl.registerMethodProcessor i.e. the
OperationSets implement MethodProcessor instead of SipListener,

- allows registering multiple MethodProcessors for one and the same method, and

- allows returning an indicator from the processXXX methods which used
to be in SipListener and are now in MethodProcessor which determines
whether the passed XXXEvent was handled by the MethodProcessor - true
means the event was handled by the processor and shouldn't be passes
to the other processors for the same method and false means the
processor hasn't handled the passed event and it should be passed to
the next processor registered for the same method.

If I'm not mistaken, this should allow you to register multiple
OperationSets to handle one and the same INVITE request.

Best regards,
Lubo

···

On Mon, Aug 25, 2008 at 6:08 PM, Joao Antunes <joao.antunes@tagus.ist.utl.pt> wrote:

Hi fellow devs!

I'm the GSoC student responsible for implementing SC's SIP File Transfer.
Currently the file-transfer is implemented with issues, i would describe it
as a liana bridge, you can use it, but definitely there is space for
improvement.

Anyway, for the file transfer purposes i needed to allow multiple
OperationSets [OperationSetBasicTelephony and
OperationSetFileTransferSipImpl] to register on the provider so that i could
process the incoming SIP INVITE requests that it's how the file transfer is
negotiated. So, basicly i ended up registering both operation sets so that
both of them get called when there is an INVITE and what i did was that on
the processRequest, i checked the body of the incoming SDP offer to see if
it had a 'file-selector' attribute, if it did the processRequest of the
OperationSetFileTransferSipImpl continued processing the INVITE, if it
didn't then OperationSetBasicTelephony would take care of it.

That solution has a problem inherent to it because supposedly the SDP body
could have multiple media lines and multiple kinds of sessions so that one
could negotiate, with the same invite, a call and a file transfer, therefore
the end result is that such mixed sessions only get processed for their file
transfer (because they must have the file-selector) attribute.

I'm not sure if this changes anything in the problem being discussed or in
the solution, i just felt obliged to write about this variable to warn you
about this need.

My solution proposal to support these kind of mixed sessions would be to
somehow abstract the OperationSets from the SIP protocol and only make them
add or remove things in the SDP.

I apologise if i eventually only added noise to the discussion.

Regards,
João Antunes

On Mon, Aug 25, 2008 at 12:45 PM, Lubomir Marinov > <lubomir.marinov@gmail.com> wrote:

If Dialog.getApplicationData/setApplicationData is to be used, please
note that I use it in
net.java.sip.communicator.impl.protocol.sip.DialogUtils.

Thanks,
Lubo

On Mon, Aug 25, 2008 at 2:37 PM, Emil Ivov <emcho@sip-communicator.org> >> wrote:
> Hey Sebastien,
>
> We just had a quick offline chat with Lubomir on this. We are probably
> going to make the method processors have an interface of their own
> rather than using SipListeners. This way we'll be able to register
> several processors for the same sip method. The new interface will also
> provide them with a way to indicate whether they have handled a
> particular event or not. (I actually see now that he has already
> explained this)
>
> Concerning your registerDialogProcessor() suggestion. Sounds nice but I
> am worried about the programming overhead. This would require operation
> sets to register themselves as a processor for every dialog they create.
> If we are going to use a single port for all accounts then I'd like us
> to have all the mux/demux functionality in a single place.
>
> Now, I thought about this since our talk yesterday and here's what I
> suggest: both the Dialog and the Transaction interfaces have the
> following two methods:
>
> public void setApplicationData(Object applicationData);
> public Object getApplicationData();
>
> They are meant for applications to tag dialogs and transaction with
> stateful, dialog/transaction dependent information. I think we could
> easily implement all muxing/demuxing with them. We can even make them
> almost transparent for the rest of the application. We just need to make
> sure that all dialogs and transactions get tagged with a reference to
> the owning SC provider when they are created. It would probably also be
> a good idea to make sure that no dialogs nor transactions can be created
> within SC without attaching the corresponding tag. We would probably
> need to restrict access to the jain sip providers in order to achieve
> this.
>
> Concerning server dialogs and transactions (i.e. the ones that are going
> to be initiated by our interlocutors or servers). You can set their
> application data in the message dispatcher that you mentioned yesterday.
> How exactly we are going to determine which provider an incoming dialog
> or tran are meant for, is a different story. Ideally the To header
> should contain our registration address and this is probably going to be
> enough in the majority of the cases.
>
> I am quite certain that we're still going to run into cases where this
> is not going to be enough but I believe we can limit them to a
> reasonably low number.
>
> What do you think?
>
> Cheers
> Emil
>
>
> Sébastien Mazy написа:
>> Hi All,
>>
>> From Lubomir Marinov's last commit:
>>
>> On Mon, Aug 25, 2008 at 4:10 AM, <lubomir_m@dev.java.net> wrote:
>>> Log:
>>> Implements initiating call transfer (in addition to responding to call
>>> transfer requests which was introduced in a previous revision). It will
>>> still not work because the telephony OperationSet needs to be a
>>> Request.NOTIFY method processor but the presence OperationSet will overwrite
>>> its registration since only one processor is supported for each type of
>>> Request method.
>>
>> Since I'm in the process of making the SIP service implementation use
>> a single JAIN-SIP stack whatever the number of SIP accounts registered
>> is, I have precisely to deal with how to find which a response event
>> should be dispatched to. How about registering JAIN-SIP's DialogS
>> processors?
>>
>> You would have two methods:
>> - registerDefaultMethodProcessor() used to dispatch incoming new
>> requests (ie currently unknown JAIN-SIP's DialogS)
>> - registerDialogProcessor() used to dispatch incoming messages related
>> to the registered Dialog (for example "NOTIFY presence" would go to
>> the instance which first sent the "SUBSCRIBE presence" request).
>>
>> The tricky part would be to unregister the DialogS. Dialog.getState()
>> might get used to achieve this.
>>
>> What do you think of that?
>>
>> Cheers,
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>
>


#9

Hi all,

Concerning your registerDialogProcessor() suggestion. Sounds nice but I
am worried about the programming overhead. This would require operation
sets to register themselves as a processor for every dialog they create.

Just for the record: We had a talk yesterday and agreed that
registering a mandatory listener for every dialog is a bad idea.

Now, I thought about this since our talk yesterday and here's what I
suggest: both the Dialog and the Transaction interfaces have the
following two methods:

   public void setApplicationData(Object applicationData);
   public Object getApplicationData();

They are meant for applications to tag dialogs and transaction with
stateful, dialog/transaction dependent information. I think we could
easily implement all muxing/demuxing with them.

Sure. These methods are very handy.

We can even make them
almost transparent for the rest of the application. We just need to make
sure that all dialogs and transactions get tagged with a reference to
the owning SC provider when they are created. It would probably also be
a good idea to make sure that no dialogs nor transactions can be created
within SC without attaching the corresponding tag. We would probably
need to restrict access to the jain sip providers in order to achieve this.

Currently I'm implementing it in the following way:
- "SipProvider ProviderServiceSipImpl.getJainSipProvider(String
transport)" will return a VirtualSipProvider
- VirtualSipProvider is a wrapper around the real SipProvider
(instance of SipProviderImpl), the only difference is that it tags
every created dialog (is it needed to tag transactions? can I have a
transaction without a dialog?). There is one VirtualSipProvider per
transport per ProtocolProviderServiceSipImpl instance (so basically 3
per account).
- there is only one instanciated SipMessageDispatcher whatever the
number of ProtocolProviderSipImpl is (it is a static field of
ProtocolProviderServiceSipImpl). This single instance is the
SipListener for every "real" SipProvider (ie instance of
SipProviderImpl). It directly dispatches received events whose DialogS
are tagged to the proper ProtocolProviderServiceSipImpl (so that it
will be processed as before and be sent to an OpSet).

So:
- It will be completely transparent for OpSets. Not a single line of
them will be changed.
- Dialogs we initiated would be dispatched quickly and reliably
- for Dialogs we didn't initiate (non tagged), see below

If Dialog.getApplicationData/setApplicationData is to be used, please
note that I use it in
net.java.sip.communicator.impl.protocol.sip.DialogUtils.

Noted. I'll be careful no to break that. I even think of not using
setApplicationData to make that fully transparent. Since I created
VirtualSipProvider, I could also create a new field in the Dialog
returned by getNewDialog().

Enrico also suggesting having a look at the use part of the request URI
in addition to analysing the whole URI. Here's what this gives us:

1. Check if the TO header matches any of our AORs
2. Check if the Request URI matches any of our AORs
3. Check if the user part of the request URI matches the user part of
any of our AORs
4. Forward to a default account.

Does this make sense?

According to http://wiki.voip.co.uk/sip/matching_using_to_header, the
only reliable way to guess which account an incoming message is
addressed to is by looking at the Request-URI, because it shoud match
the contact header field sent to the registrar (if we have a registrar
of course). And as this contact header contains our own IP address or
hostname, you can only check the user part of the Request-URI. (That
would explain why Twinkle doesn't allow to have two accounts with the
same contact user part.)

So I would change the order:
1. Check if the user part of the request URI matches the user part of
any of our AORs only if all of our AORs have different user parts
2. Check if the TO header matches any of our AORs
3. Forward to a default account (which could be the one without a
registrar if it exists).

And so we would handle the case where the user decided to redirect
calls to one SIP account to another (and both are registrated in SC).
Yes, that's really a corner case :wink:

Anyway, for the file transfer purposes i needed to allow multiple
OperationSets [OperationSetBasicTelephony and
OperationSetFileTransferSipImpl] to register on the provider so that i could
process the incoming SIP INVITE requests that it's how the file transfer is
negotiated. So, basicly i ended up registering both operation sets so that
both of them get called when there is an INVITE and what i did was that on
the processRequest, i checked the body of the incoming SDP offer to see if
it had a 'file-selector' attribute, if it did the processRequest of the
OperationSetFileTransferSipImpl continued processing the INVITE, if it
didn't then OperationSetBasicTelephony would take care of it.

As for the problem of registering the same request (most of a time a
NOTIFY) twice, I'm still convinced it could be a good idea to provide
a way to create a per-Dialog listener when you want to, it would just
add a few lines of code to ProtcolProviderServiceSipImpl. A new
method, for example getNewDialog(SipListener aListener), would allow
to bypass the default SipListener (the related
ProtocolProviderServiceSipImpl) for this dialog only. But for the
moment, I'll only concentrate on the above issues.

I know long and with quotations mails are hard to read, sorry.

Cheers,

···

On Mon, Aug 25, 2008 at 1:37 PM, Emil Ivov <emcho@sip-communicator.org> wrote:
On Mon, Aug 25, 2008 at 1:45 PM, Lubomir Marinov <lubomir.marinov@gmail.com> wrote:
On Mon, Aug 25, 2008 at 5:04 PM, Emil Ivov <emcho@sip-communicator.org> wrote:
On Mon, Aug 25, 2008 at 5:08 PM, Joao Antunes <joao.antunes@tagus.ist.utl.pt> wrote:

--
Sébastien Mazy


#10

Sébastien Mazy wrote:

So I would change the order:
1. Check if the user part of the request URI matches the user part of
any of our AORs only if all of our AORs have different user parts
2. Check if the TO header matches any of our AORs
3. Forward to a default account (which could be the one without a
registrar if it exists).

Well, it may make sense to use the request URI even if some accounts
have the same username, and just fall back on To header if it actually
matches more then one, no?

···

--
Ciao,
Enrico


#11

Hey Seb,

Sébastien Mazy написа:

And so we would handle the case where the user decided to redirect
calls to one SIP account to another (and both are registrated in SC).
Yes, that's really a corner case :wink:

Well, we'd still be in trouble if both accounts had the same user part
(which is actually relatively common), but anyways, we are not doing any
forwarding right now so I guess that's OK. Besides I am quite reluctant
to start mangling the user part of the contact URI so we'll worry about
that when we actually implement call forwarding in the client.

Otherwise, your change is fine with me.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hi Enrico,

Well, it may make sense to use the request URI even if some accounts
have the same username, and just fall back on To header if it actually
matches more then one, no?

Yes, I think that's actually the best solution:
1. Count the number of accounts whose user part in the SIP URI matches
the user part of the Request-URI
2.1 if it is == 1: dispatch
2.2 If it is > 1 and an account whose domain part is in the SIP URI
matches the To header field in the request: dispatch

Fallback (we could also drop the request at this state):
3. if the To header field matches our SIP URI: dispatch
4.if the domain in the To header field matches our SIP URI's domain: dispatch
5. if the user in the To header field matches our SIP URI's domain: dispatch
6. forward to any account?

Cheers,

···

On Tue, Aug 26, 2008 at 3:12 PM, Enrico Marocco <enrico.marocco@telecomitalia.it> wrote:

--
Sébastien Mazy


#13

Hello Sebastien,

Sébastien Mazy написа:

1. Count the number of accounts whose user part in the SIP URI matches
the user part of the Request-URI
2.1 if it is == 1: dispatch
2.2 If it is > 1 and an account whose domain part is in the SIP URI
matches the To header field in the request: dispatch

Not sure I get 2.2. Did you mean "user part" rather than "domain part"?

Fallback (we could also drop the request at this state):
3. if the To header field matches our SIP URI: dispatch

Keep in mind that in reality this is probably where we'd be able to
determine the account for most requests. We always register with the
same domain part in our Contact URI (i.e. the IP address of the local
interface that was used to send the REGISTER request) and users often
choose the same user name across different providers.

This means that you could easily end up in situations where the Request
URI in an incoming request completely matches the Contact addresses of
more than 1 and possibly all local accounts (this is actually what I
currently have).

Your best option in such cases 1 and 2.1, then compare the AORs of all
your accounts to the To header of the incoming request and return the
first match.

True, this would fall into an endless loop in a case where a local
account with an a@x.com AOR forwards to another local account which is
a@y.com but this is not currently an issue because:

1. We don't support intra client forwards yet
2. If we ever decide to implement them we can either prevent the user
from creating "loopy" rules, or somehow tag the requests we forward so
that we recognize it at reception (e.g. by using the header mentioned in
the article you quoted earlier today).

But then again, we're not there yet. :slight_smile:

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Hi all,

OK, attached is a first snapshot. It's work in progress so there are
regressions. For example, outbound proxy option is not respected
(though in most cases it will work because you often call
sip:someone@yourproxy and the SIP stack default router would send the
INVITE to youproxy).

I've dropped the idea of tagging DialogS and TransactionS. I actually
implemented it and it only help solve the trivial cases (so it was
useless). I've also tried to have a single SipProvider for all SIP
accounts but this caused a problem since you can"t add a TCP
ListeningPoint and a TLS ListeningPoint on the same SipProvider
(ListeningPointS for a same SipProvider should all have same IP and
port).

The "interesting" changes are in SipMessageDispatcher. In the
processRequest() method there are 9 dispatch cases, based on the
previous discussions. Case 0 should apply 95% of the time.

The patch applies on revision 4356 from svn.

Cheers,

single_sip_stack-0.patch (33.7 KB)

···

--
Sébastien Mazy